AD-A1Q0  318  JET  PROPULSION  LAB  PASADENA  CA 

AUTONOMOUS  SPACECRAFT  MAINTENANCE  STUDY  SROUP.(U) 

FEB  81  M  H  MARSHALL »  G  D  LOW  NAS7-100 

UNCLASSIFIED  JPL-PUB-80-88  AFOSR-TR-81-0518 


DT1C  FILE  COPY 


SFOSR-TR-  8  1  •  0  5  18 


a 


Final  Report  of  the  Autonomous 
Spacecraft  Maintenance  Study  Group 

Michael  H.  Marshall 
G.  David  Low 


February  1,  1981 


Prepared  for 

The  Air  Force  Office  of  Scientific  Research 

Through  an  agreement  with 

National  Aeronautics  and  Space  Administration 

by 

Jet  Propulsion  Laboratory 

California  Institute  of  Technology 
Pasadena,  California 


\  Approved  for  puMfe  release ; 
distribution  uai  lotted. 

,  ft,  6  i2  136 


UNCLASS  I*  iKli 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (VEhwn  Data  Entered) 


EPORT  DOCUMENTATION  PAGE 


RKAD  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


4.  TITLE  (and  Subtitle) 

AUTONOMOUS  SPACECRAFT  MAINTENANCE  STUDY 

GROUP 

5  TYPE  OF  REPORT  6  PERIOD  COVERED 

f 

|— '  FINAL 

6.  performing  org.  report  number 

1 

i  mi. 

7.  AUTHOR^ 

[  B.  CONTRACT  OR  GRANT  NUMBER^ 

MT  H.  '  MARSHALL 

G.  DAVID  LOW 

1  . 

y 

1 

1  NAS  7- 100 

1  ■ 

^rFrrORRtf+Y^-OfTG'ANTZATlON  NAME  AND  ADDRESS 

Jet  Propulsion  Laboratory 

California  Institute  of  Technology 

Pasadena,  California 

10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  6  WORK  UNIT  NUMBERS 

61 102 F  RD-182 

11.  CONTROLLING  OFFICE  NAME  AND  AOORESS 

AFOSR/XOT 

^7] 

12.  REPORT  DATE 

Feb  l,.  .*981 

BLDG  410 

BOLLING  AFB ,  DC  20332 

i 

13.  NUMBER  OF  PAGES 

40 

U.  MONITORING  AGENCY  NAME  &  ADDRESS  (if  different  from  Controlling  Office) 

National  Aeronautics  and  Space  Administration 
Headquarters 

IS.  SECURITY  CLASS,  (of  th is  report) 

UNCLASS  I  FI  ED 

Washington,  DC 

15a  DECL  ASSlFiCATION  DOWNGRADING 
SCHEDULE 

16.  DISTRIBUTION  STATEMENT  (of  this  Report) 

Approve  for  public  release;  distribution 

uni imi t  ed 

i  7  ‘  ' 

17.  DISTRIBUTION  STATEMENT  (of  the  abstract  entered  in  Block  20, 

//  different  from  Report) 

19.  KEY  WORDS  (ConUnue  on  reverse  side  if  necessary  and  identify  by  block  number) 

spacecraft  system  technology 
f au 1 t-to 1 e ran t  computing 
autonomous  spacecraft  maintenance 


20  ABSTRACT  (Continue  on  reverse  side  if  necessary  end  identify  by  block  number) 


This  report  outlines  a  plan  to  incorporate  autonomous  spacecraft  maintenance 
(ASM)  capabilities  into  Air  Force  spacecraft  by  1989.  These  capabilities 
include  the  successful  operation  of  the  spacecraft  without  ground-operator 
intervention  for  extended  periods  of  time.  Autonmous  maintenance  requires 
extensive  use  of  onboard  fault  detection,  isolation,  and  recovery  mechanisms 
integrated  into  the  spacecraft  within  a  hierarchical  architecture.  These 
mechanisms,  along  with  a  fault-tolerant  data  processing  system  (Cent,. 'I 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  'When  Data  Entered) 


1  J  AN  ^7  3  1473  EDITION  of  f  NOV  65  IS  OBSOLETE 


SECURITY  CLASSIFICATION  of  THIS  PAGEfH7ien  Date  Entered) 


20.  Cont. 

(including  a  nonvolatile  backup  memory)  and  an  aptdnqfcous  Jn^vig^  <pn  capability 
needed  to  replace  the  routine  servicing  that  is  presently  performed  by' 
the  ground  system. 

As  part  of  this  study,  the  state-of-the-art  fault-handling  capabilities  of 
various  spacecraft  and  computers  are  described,  and  a  set  oi  conceptual  design 
requirements  needed  to  achieve  ASM  are  established.  From  these  two  inputs, 
an  implementation  plan  describing  near-term  technology  development  needed  for 
an  proo f-o f-concept  demonstration  by  1985,  and  a  research  agenda  addressinj 

long-range  academic  research  for  an  advanced  ASM  system  of  the  1990,s,  are 
es tabl  i shed . 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  P  A  G  EfHViort  Data  Entered) 


*  * 


JPL  PUBLICATION  80-88 


Final  Report  of  the  Autonomous 
Spacecraft  Maintenance  Study  Group 

Michael  H.  Marshall 
G.  David  Low 


Approved: 


&.&JL 


C.  Carl,  Study  Manager 


Y  N.  Bryden,  Defense  Technology 
jnd  Program  Development 
Office  Manager 


February  1,  1981 


A-' 


Prepared  for 

The  Air  Force  Office  of  Scientific  Research 
Through  an  agreement  with 
National  Aeronautics  and  Space  Administration 

by 

Jet  Propulsion  Laboratory  ■ 

California  Institute  of  Technology*11*  FORCE  office  cw  scientific  Research  iafsci 
Pasadena,  California  notice  OF  transmittal  to  nnr* 


r'  ■ 

Av 

iDict 

k 


NOTICE  OF  TRANSMITTAL  TO  DDC 
This  technical  report  baa  boon  reviewed  and  la 
approved  for  public  release  IAW  AIR  190-12  /7hi 
Distribution  is  unlimited.  J 
A.  D.  BLOSE 

XaobnlotU  Ixct ermntl<uH Qf fleer  _ 


The  research  described  in  this  publication  was  carried  out  by  the  Jet  Propulsion  Lab¬ 
oratory,  California  Institute  of  Technology,  and  was  sponsored  by  the  Air  Force  Office 
of  Scientific  Research  through  an  agreement  with  NASA. 


Preface 


As  currently  designed  and  flown,  spacecraft  need  considerable  maintenance  to  perform 
their  missions  Mission  readiness  is  jeopardized,  however,  because  the  ground  support  that 
provides  the  maintenance  is  vulnerable  to  both  hostile  action  and  operator  errors.  To 
address  this,  the  Jet  Propulsion  Laboratory  ( JPL),  California  Institute  of  Technology,  was 
commissioned  in  March  FLSO  by  the  Air  Force  Office  of  Scientific  Research  to  lead  a 
study  ot  autonomous  spacecraft  maintenance  (ASM).  ASM  is  a  spacecraft  design  that 
tolerates  hardware  and  software  fadures  and  design  faults,  while  requiring  minimum 
giourul  contact  to  perform  the  mission.  The  study  group,  composed  of  experts  from 
mdustrv.  academia,  and  NASA,  was  to  identify  ciitical  issues  related  to  ASM  technology 
development  and  detail  the  infusion  of  this  technology  into  future  Air  Force  spacecraft 
systems.  To  facilitate  this,  three  subgroups  were  formed:  the  Spacecraft  System  Tech¬ 
nology  Working  Group,  composed  of  spacecraft  system  specialists  from  various  spacecraft 
suppliers,  the  Fault -Tolerant  Technology  Working  Group,  composed  of  specialists  in 
fault-to.erant  computer  technology  from  academic  and  independent  research  institutions: 
and  the  Academic  Assessment  C  ommittee,  comprised  of  leading  researchers  from  academic 
and  independent  research  institutions. 

These  groups  weie  brought  together  in  a  series  of  three  workshops  field  at  JPL  in  May. 
July,  and  August  10, so.  under  the  guidance  of  the  Study  Planning  Committee.  7'he 
spacecraft  systems  and  fault -tolerant  working  group  members  presented  their  organiza¬ 
tions'  cui rent  capabilities  in  spacecraft  and  fault-tolerant  computers,  respectively,  from 
which  a  state-of-ihe-ai 1  technical  data  base  was  established.  A  set  of  conceptual  design 
requirements  was  then  developed,  detailing  what  an  ASM  spacecraft  must  do.  Thus, 
knowing  on  one  hand  capabilities  of  current  spacecraft,  and.  on  the  other,  the  require¬ 
ments  lor  ASM.  the  working  groups  began  a  search  for  the  optimum  plan  for  the  integra¬ 
tion  of  ASM  into  spaceci alt. 

The  majoi  product  the  Spacecraft  System  Technology  Working  Group  was  the 
Implementation  Plan,  which  details  the  group  s  recommended  approach  for  incorporating 
AS;  1  capabilities  into  operational  spacecraft  by  The  Fault-Tolerant  Technology 

Working  Group  and  the  Academic  Assessment  Committee  together  established  the 
Researc!  Agenda,  which  outlines  basic  research  activities  required  to  fill  technological 
gaps. 

It  i>  hoped  that  the  mat  'rial  presetted  here  will  provide  guidance  for  the  evolution 
of  luture  spacecraft  systems  file  study  participants  believe  that  the  interaction  between 
the  working  gmups  has  been  s\nergtstic.  and  has  contributed  to  an  increased  awareness 
of  potential  technologs  capabilities. 
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Abstract 


This  report  outlines  a  plan  to  incorporate  autonomous  spacecraft  maintenance  (ASM) 
capabilities  into  Air  Force  spacecraft  by  1989.  These  capabilities  include  the  successful 
operation  of  the  spacecraft  without  ground-operator  intervention  foi  extended  periods  of 
time.  Autonomous  maintenance  requires  extensive  use  of  onboard  fault  detection,  isola¬ 
tion,  and  recovery  mechanisms  integrated  into  the  spacecraft  within  a  hierarchical  archi¬ 
tecture  These  mechanisms,  along  with  a  fault-tolerant  data  processing  system  (including  a 
nonvolatile  backup  memory)  and  an  autonomous  navigation  capability,  are  needed  to 
replace  the  routine  servicing  that  is  presently  performed  by  t he  ground  system. 

As  part  of  this  study,  the  state-of-the-art  fault-handling  capabilities  of  various  space¬ 
craft  and  computers  are  described,  and  a  set  of  conceptual  design  requirements  needed 
to  achieve  ASM  are  established.  From  these  two  inputs,  an  implementation  plan  describ¬ 
ing  near-term  technology  development  needed  for  an  ASM  proof-of-coneept  demonstra¬ 
tion  by  1985,  and  a  research  agenda  addressing  long-range  academic  research  for  an 
advanced  ASM  system  of  the  1990s,  are  established. 
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Executive  Summary 


I.  Introduction 

Spaceciatt  are  presently  designed  to  interact  with  the 
giound-conirol  operations  centei  tor  routine  maintenance  and 
tot  fault  diagnosis  and  recontiguiation  in  the  event  of  onhoaid 
ptohloms.  During  periods  ot  conflict,  however,  the  contiol 
operations  centei  is  vulneiahtc  u>  hostile  action  lo  continue 
opet at i’. »n  during  these  periods,  spacecraft  must  he  capable  of 
autonomously  performing  predetermined  ground  functionsithis 
is  accomplished  by  autonomon-  spaceciatt  maintenance 
(  ASM)  ASM  maintains  the  spaceciatt  in  a  state  ot  readiness  h\ 
pi' Aiding  spaceciatt  designs  that  require  no  ground  contact 
in  lei  action  loi  onhoaid  detection,  isolation,  and  mcoveiv 
hom  limits  or  tor  routine  operations  such  as  power  manage¬ 
ment . 

lire  study  gioup  vvas  cotntni*  stoned  to  determine  a  v\.r\  to 
mempoiate  \SM  into  spacecraft  l o  do  this,  they  tits!  made 
state-o-l-the-ai 1  technology  assessment  o)  cimcui  spaceciatt 
s\  stems,  ami  t f  101 1  determined  some  general  requirements  )»m 
an  ASM  -.paccctatt  from  this,  tliev  developed  the  1  tuple  - 
mentation  Plan  that  leads  to  the  »tco/j>o/aijon  ot  ASM  into 
operational  spaceciatt  h\  ll>Nl>  Included  m  tills  was  an 
identi! ication  o|  the  rteeded  technologies  to  til)  immediate 
gaps,  fo  address  longei-tenn  technology  issues  lor  use  m  a 
socoiul-gene»ari«iir  ASM  sfMcecr.il!  oj  the  !',,,(K.  the  study 
group  a!-1  developed  ihe  Reseat ch  Vaenda. 

II.  State-of-the-Art  Technology 

I  lie  memheis  o|  the  working  groups  pieseuted  examples  ol 
eiineiit  spacecialt  and  taulMolerairt  computer  systems. 


describing  then  fault -handling  characteristics  l  xamples  oi  the 
spaceciatt  presented  vveie.  H.TSAKOM  ami  I  I  ASA l  (mm- 
imimcations).  (ilohal  Positioning  System  (navigation).  Detense 
Meleoiological  Satellite  Program  (meteorological ).  NASA's 
Muliimission  Modular  Spaceciatt  ( multmusMon  ).  and  \  o\  ager 
(planetary  exploration ).  Although  each  of  these  spacecraft 
peitoim  some  functions  autonomously .  none  is  capable  ot 
lulls  autonomous  operation,  mainly  because  th/>  capab/btv 
lias  nevei  been  requited  oi  spoilt  ted  Ihe  fault  -t  i  >ler  .tn  t 
compuleis  described  were  I  ault- 1  olcunt  Spacebome  Corn- 
putei  and  Building  block  I  ault- 1  olei.mi  (omputei  (space- 
home).  (  .nimp.  Cm*,  and  (  unp  (commercial ).  and  Soitware 
Implemented  I  ault -Tolerance  and  I  ault- 1  olei.mi  Multipro¬ 
cessor  ( commercial  aviation).  Ot  the  laulMolerant  compuleis 
presented.  none  is  »  qvrath  mal  y  ot .  and  only  the  I  ault  -  I  ole  taut 
Spacebome  (  omputer  and  building  Block  Krult-1  ’oleiant 
(  ompulet  will  bo  applicable  to  spaceciat’t  systems  Ihe  others, 
however,  provided  examples  ol  design  methodologies  and 
techniques  that  may  be  applicable  lo  spacebome  compuleis 

l  aclt  ol  the  spaceciatt  that  was  picsented  requited  inieuu* 
(tofr  uuh  (he  ground  system  tor  nonn.J  operations  manage¬ 
ment.  as  well  as  tault  diagnosis  and  recovers  1  his  mtei action 
was  needed  for  such  tilings  as  powet  man  igernent .  housekeep¬ 
ing.  navigation  collections,  and  an\  abnormalities  that 
occurred  Having  ihe  spaceciatt  rely  on  the  contiol  operations 
centei  makes  the  overall  space  system  as  vulnetable  as  the 
control  opeuuons  center  It  also  cieates  a  long  "down  time” 
wherever  a  fault  occm\.  because  the  tault  must  be  diagnosed 
and  leconligmation  commands  must  be  developed  by  the 
contiol  i  peiations  center.  I’lus  vulnerability  and  down  time 
can  be  leduced  In  slutting  the  management  of  routine 


operation?*  and  fault  handling  I'roni  the  ground  to  the 
spacecraft  (i.e.,  ilie  spacecraft  performs  them  auionomously). 

Thus,  the  need  for  ASM  is  recognized;  furthermore.  the 
study  group  believes  that  the  technology  available  in  today's 
spacecraft  systems  is  a  good  foundation  fiom  which  to 
proceed  to  ASM. 

III.  The  ASM-Enhanced  System 

The  impact  of  ASM  on  future  An  Foico  spaceciaft  is  based 
upon  an  analysis  of  the  cuneni  system's  ability  to  meet  the 
candidate  design  requirements  humiliated  by  the  studs  gioup. 
In  summary,  these  ASM  conceptual  design  lequiiemenis  are. 

( 1 )  The  ASM  spacecraft  shall  operate  without  giound 
intervention  tor  up  to  oU  Jays  with  no  peiformance 
degradation,  and  up  to  h  months  with  degiaded.  but 
acceptable,  performance.  (The  actual  peiiods  of  auto- 
nomy  may  van  with  different  mission  applications; 
however,  the  participants  fell  that  these  were  worth¬ 
while  goals  for  this  study.) 

(21  ASM  shall  not  reduce  the  spacecrafts’  performance  01 
design  lifetime. 

(3)  The  ground  segment  shall  always  he  able  to  override 
ASM  actions  and  interrogate  the  spacecraft  foi  fault- 
management  data  (audit  1 1 ails f. 

Satisfying  these  design  requirements  implies  the  movement 
of  loutine  maintenance  and  operations  from  the  giound 
segment  to  the  space  segment  The  control  opeiations  center 
will  assume  a  supervisoiy  lole.  pviteni tally  less  complex,  while 
the  space  segment  will  become  more  complex.  The  lesultmg 
benefits  of  ASM  would  then  include:  (!)  reduced  system 
vulnei ability  because  the  spacecraft  is  no  longei  dependent 
upon  the  control  operations  ccntoi  and  (2)fastei  recovet y 
from  failures  ( seconds  instead  of  hours  or  possibly  days). 

I  lie  impact  of  ASM  on  spaceciaft  design  is  expected  to  he 
evolutionary  Iiaditional  subsystems  are  expected  to  be 
augmented  by  two  new  subsystems  a  tault-ioleiant  data 
processing  subsystem  with  nonvolatile  back-up  memory,  and 
an  autonomous  navigation  subsystem. 

lire  system  architectme  is  expected  to  possess  a  “lavered" 
fault-protection  scheme,  enabling  fault  containment  at  the 
lowest  possible  level  to  mimnn/e  subsystem  inter  dependencies. 
In  this  scheme,  individual  subsystems,  under  svstem  coniiol. 
will  be  icquucd  to  diagnose  local  (ailuies  and  fake  corrective 
action  I  he  system  will  he  required  to  diagnose  and  correct 
ambiguous  failures  within  the  subsystem  interlaces  and  ASM 
mechanisms  themselves,  as  well  as  to  judiciously  allocate  the 
sv  stem  resources 


IV.  Implementation  Plan 

Hie  Implementation  Plan  focuses  on  neat -term  industrial 
technology  development  and.  most  importantly,  the  earliest 
possible  system-level  proof-of -concept  demonstration  (ll)85) 
to  support  a  IW/  launch.  The  plan  stresses  delivery  of 
“product"  in  a  steady  stream  from  subsystems  to  a  complete 
system  for  the  System  Program  Offices'  consideration  and 
introduction  into  flight  progiams. 

As  shown  in  f  ig.  1,  the  Implementation  Plan  consists  of 
four  major  tasks  These  are:  ( 1 )  redesign  of  existing  subsys¬ 
tems  to  characterize  and  demonstrate  ASM  capabilities; 
(2)  design,  develop,  and  test  an  ASM  system  demonstration 
breadboard  to  show  that  ASM  is  a  viable  concept;  (3)  perforin 
applications  research  required  to  develop  an  autonomous 
navigation  capability  and  a  fault-tolerant  data  processing 
capability  to  til!  existing  technology  gaps;  and  (4)  basic 
research  needed  to  develop  a  second-generation  ASM  system 
tor  the  lc)lK)s.  A  section  of  this  report.  “Research  Agenda." 
elaborates  upon  Task  4. 

A  budge taiy  resource  estimate  for  the  proposed  ASM 
program  is  S3(v4M  (FY80  dollars)  over  five  years.  For  several 
reasons,  this  figure  should  be  considered  only  an  estimate. 
First,  the  cost  of  developing  the  new  technology  is  not  well 
known.  Second,  a  specific  mission  application  has  not  been 
assumed,  and  so  candidate  spacecraft  could  not  be  assumed. 
Finally,  sub stunimting  data  was  not  provided  by  the  industrial 
participants.  For  these  reasons,  a  mote  definitive  cost  study 
should  be  performed  in  the  initial  phase  of  the  activity 

V.  Research  Agenda 

The  Research  Agenda  proposes  basic  research  that  is  a 
synergistic  part  ol  the  ASM  program.  Future  ASM  develop¬ 
ment  activities  ;ue  focused  on  five  aieas  (  1)  ver  y  -large-scale 
integration  ( \  l  S I  >  technology .  which  includes  sell-testing 
VI  SI  and  on-chip  redundancy ■;  (2)  system  architecture,  which 
addresses  spaceciaft  organizational  issues,  architectural  devel¬ 
opments.  and  advanced  system  studies;  (3)  software  fault 
tolerance,  consist  mg  ol  system  partitioning  and  interface 
definition,  self-checking  flight  software,  and  faiilt-toleiant 
software;  (4)  modeling  and  analysis,  composed  of  experi¬ 
mental  resting,  statistical  modeling,  and  Umciional  descrip¬ 
tion.  modeling,  and  verification;  and  (M  supporting  develop¬ 
ments  needed  to  formulate  an  ASM  data  base,  and  lo  build  an 
ASM  spacecraft  laboiatory . 

VI.  Conclusions  and  Recommendations 

The  following  conclusions  and  recommendation  are  those 
ot  the  study  gioup  paiticipants.  resulting  from  analysis  of  the 
material  developed  dining  the  workshops. 
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A.  Conclusions 

I  1  1  \SM.  fully  implemented.  would  leduce  spiKe  s\  si  cm 
V u lilt* I ;ih lilt \  h\  eliminating  Npa^Mjll  dependence  on 
the  control  operations  centei  t « »i  up  to  t>  months  at  a 
t  nno 

(  7  l  Tito  ASM  capability  need  not  impose  operational  con- 
st i aim n  on  the  system  : »sor .  it  must  ho  ’transparent” 
to  tho  user  during  normal  >vstem  operations 

!o)  ASM  would  require  a  change  in  tho  conduct  of  opera¬ 
tions  and  control.  from  dependence  on  a  man  in  tho 
loop  to  dependence  on  machines  tor  fault  handling 
and  routine  maintenaiKo  operations. 

<  4  >  ASM  would  increase  the  spacecraft  complexity, 
therefore.  now,  method.'*  I'm  specifying,  testing,  and 
validating  ASM-enlianced  spacecraft  are  needed. 

(5)  A  more  etteettve  means  of  transferring  technology 
from  research  to  applications  programs  would  he 
required  so  that  spacecraft  problems  could  be  solved 
with  the  latest  as  ail  able  technology. 

(M  New  technology  developments  would  lv  required: 
needed  are  a  highly  reliable  fauIt-folcuM  data  pro 
cessing  system  with  nonvolatile  backup  memory  to 
enable  autonomous  maintenance,  and  an  autonomous 


navigation  capability  to  enable  independence  of 
routine  ground  operations. 

(7)  ASM  would  be  a  phased  piogram;  spacecraft  would 
not  instantly  become  totally  autonomous.  The  pace 
of  ASM  development  would  depend  on  the  resources, 
technology,  and  chosen  progtam  applications  that  are 
available.  A  strong  corporate  commit  men  l  to  ASM  by 
the  Air  Force,  along  with  a  willingness  by  industry  to 
assimilate  ASM.  would  be  required  to  make  ASM 
successful. 

(K)  Confidence  in  ASM  must  be  instilled  by  creation  nt 
a  systematic  modeling,  analysis,  and  dcinonsti aiimt 
program. 

CM  Although  considerable  technology  developments  are 
necessary,  no  requirements  foi  technology  break¬ 
throughs  have  been  identified. 

(10)  In  the  opinion  of  the  study  group.  ASM  is  a  viable 
concept . 

B.  Recommendation 

Tire  study  gioup  recommends  that  the  ASM  research  and 
technology  development  activities,  as  outlined  in  the  Imple¬ 
mentation  Plan  and  Research  Agenda  sections  ot  this  report, 
be  initiated  a;>  soon  as  possible  Tins  would  enable  the  earliest 
possible  spacecraft  system-level  proof-of-concepi  demonstra¬ 
tion  of  ASM . 


TASK  3:  APPLICATIONS  RESEARCH 


NEW  TECHNOLOGY  DEVELOPMENT 

TASK  4;  ADVANCED  DEVELOPMENT 


PROOF  OF  CONCEPT 
*  DEMONSTRATION 


RESEARCH 


NEW  TECHNOLOGY  DEVELOPMENT 


CY01 

1 

j  CY82 

CY83 

1 

CY&4  | 

1  1 

CY85 

1 

1 

CY86 

Fig  1 

Implementation  plan  outline 

3 


Introduction 


Currently,  when  certain  critical  failure  states  are  detected, 
spacecraft  usually  enter  a  “'safe-hold**  mode:  in  this  mode, 
operations  are  suspended  and  ground  intervention  in  the  form 
of  reconfiguration  commands  is  required  to  restore  normal 
opeiations.  Spacecraft  are  also  not  presently  designed  to  auton¬ 
omously  recover  from  design  faults,  software  failures,  or 
changing  environmental  conditions. 

Autonomous  spacecraft  maintenance  is  characterized  by: 

( I  >  Spacecraft  design  that  tolerates  hardware  and  software 
failures  and  design  faults. 

(2  )  Spacecraft  design  that  requires  for  extended  periods 
of  tune  virtually  no  ground  contaet/intcraction  for 
onboard  detection,  isolation,  and  recovery  of  faults,  or 
routine  maintenance  functions. 

For  the  most  part,  such  capabilities  have  been  beyond  the 
state  of  the  art  of  spacecraft  systems.  This  study  group  has 
been  commissioned  by  the  Air  Force  to  address  these  issues, 
and  to  detail  a  plan  leading  to  the  incorporation  of  ASM  into 
operational  spacecraft  by  1C>HC). 


I.  Current  Space  Systems 

The  space  system  is  composed  of  the  space  segment  and 
the  ground  segment,  as  illustrated  in  Fig.  2.  For  this  study,  the 


space  segment  consists  of  only  the  spacecraft,  while  the 
ground  segment  consists  of  three  separate  entities:  data 
processing  stations,  communications  centers,  and  a  control' 
operations  center.  The  data  processing  stations  and  the  com¬ 
munications  centers  may  be  numerous  and  are  pay  load-data 
users  only,  whereas  the  conn ol, operations  centet  is  nonre- 
dundant  and  is  responsible  for  the  overall  management  of  the 
spacecraft. 

II.  Definition  of  the  Problem 

It  can  be  seen  that  the  loss  of  any  single  data  processing 
station  or  communications  center  will  not  jeopardize  the  space 
segment;  on  the  other  hand,  the  loss  of  the  control /operations 
center  may  eventually  render  the  entire  space  system  ineffec¬ 
tive.  The  dependence  of  the  spacecraft  on  the  contiol'opera* 
tions  center  and  the  vulnerability  of  the  center  to  hostile 
action  and  operator  error  are  the  concerns  of  this  study 

III.  Scope  of  the  Study 

Spacecraft  autonomy  involves  several  elements:  autono¬ 
mous  spacecraft  maintenance,  autonomous  mission  sequencing 
and  control,  autonomous  navigation,  and  autonomous  pavload 
data  processing.  To  have  a  completely  autonomous  spaceciaft. 
all  of  these  elements  would  have  to  be  included.  Tins  snub, 
hnwcvei,  was  to  addiess  only  the  spacecraft  maintenance 
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(spacecraft  “health  a nd  welfare")  aspect  of  auionomy.  This 
includes  the  maintenance  of  satisfactory  system  performance 
in  the  presence  of  internal  faults,  and  the  movement  of  routine 
maintenance  functions  from  the  ground  station  to  the  space¬ 
craft.  It  is  assumed  that  other  studies  will  address  the  other 
elements  of  autonomy.  With  tins  assumption  in  mind,  the 
following  topics  were  addressed: 

( 1 )  The  state  of  the  art  of  ASM  in  spacecraft  design. 

(2)  An  ASM  design  methodology. 


(3)  An  implementation  plan  leading  to  the  demonstration 
of  ASM  concepts. 

(4)  Research  areas  applicable  to  ASM. 

(5)  A  basic  reseat ch  agenda  that  supports  the  development 
of  ASM. 

These  topics  and  their  key  results  are  discussed  in  the  sections 
that  follow. 


Fig.  2.  The  space  system 
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State-of-the-Art  Technology 


The  members  ot‘  the  Spacecraft  System  Technology  and 
Fault-Tolerant  Technology  Working  Groups  presented  descrip¬ 
tions  ot'  the  fault-handling  characteristics  of  existing  spacecraft 
and  fault -tolerant  computer  systems.  These  were  representa¬ 
tive  ot  successful  s\ stems  designed  to  operate  within  specific 
environments'  the  spacecraft  systems  for  the  space  environ¬ 
ment.  and  the  computer  systems  (to  date)  within  laboratory 
environments.  In  this  section,  a  summary  ot  the  current 
capabilities  ot  the  spacecraft  and  fault-tolerant  computer 
systems  is  given,  followed  by  an  assessment  of  their  relevance 
to  ASM. 


subject  field  and  because  of  their  affiliated  organization's 
experience  as  a  supplier  of  Air  Force  spacecraft  for  one  or 
more  of  tiie  mission  classes.  Lach  member  described  examples 
of  current  spacecraft,  explaining  its  design  methodology 
relating  to  fault  handling  Numerous  svsteim  and  subsystems 
were  described  by  the  participants  the  systems  presented  m 
this  section  aie  examples  onlv .  leprcsenting  the  different 
mission  classes  It  is  not  being  suggested  that  these  spacecraft 
are  leading  candidates  tor  then  mission  application.  Such  an 
assessment  vv.js  not  a  pait  of  the  study.  The  fault-handling 
characteristics  ot  the  following  spacecraft  will  be  described' 


I.  Spacecraft 

Air  Force  satellites  can  be  categorized  into  foui  mission 
classes,  communications,  navigation,  meteorological,  and 
surveillance.  During  the  workshops,  satellites  Horn  each  o|  the 
classes  except  surveillance  were  presented.  Because  smvcillance 
satellites  were  classified,  no  detailed  information  was  solicited 
Additionally .  presentations  were  given  dewnbing  some  o)  the 
planetary  exploration  spacecraft. 


Mission  class 


(  ommuiik.iuons 
\av  i gallon 

Meteoodogic.il 


Multunission 


TIk  members  of  the  Spacecraft  System  Technology  Work  Planetary  exploration 

ing  Group  were  chosen  because  of  their  expertise  in  the 


hxample  spaccciafi 

H  1SAK  0M.  LI  ASA T 

Global  Positioning  System 

Do  tense  Meteorological 
Satellite  Pi ogiam 

Muitimission  Modulai 
Spacecraft 

Voyagei 
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A.  Example  Spacecraft 

1.  Communications  spacecraft.  FLTSATCOM  is  a  3-axis 


stabilized,  23-channel  communications  satellite.  It  flies  in  a 
geosynchronous  orbit  and  has  a  5-year  design  life.  Four  of 
these  spacecraft  are  operational;  the  first  was  launched  on  Feb¬ 
ruary  9,  1978.  Its  fault-handling  characteristics  are  given  in 
Table  1 . 

Table  1.  FLTSATCOM  fault- handling  characteristics 

1*  a  lilt -tolerant 
attribute 

Description 

On  board 
hardware 

Reliability  achieved  by  redundant  components 
Cross-strapping 

Onboard  switching  to  “safe-hold”  mode 
Undervoltage  detection  resulting  in  automatic 
load  shed 

Battery  cell  monitor  and  sw  itching 

Command  receiver  toggle 

On  boa  rd 
software 

None 

( Wound 

assisted 

Allow  ground  intervention  for  failure  analysis 
and  switching 

Redundancy  management  on  ground 
(hound  ovenide  capability 

L.FASAT  is  a  spin-stabilized  geosynchronous  communi¬ 
cations  satellite  designated  as  a  functional  follow-on  to 
FLTSATCOM,  with  a  design  life  of  10  years.  Four  satellites 
will  be  shuttle-launched  beginning  in  1984.  These  satellites’ 
fault-handling  characteristics  are  given  in  Table  2. 

Table  2. 

LEASAT  fault- handling  characteristics 

f  lult-tnlcranl 
attribute 

Descri  ption 

f Jnhoa'd 
hardware 

Automatic  transfer  to  rate-hold  mode  in  event  of 
loss  of  sensor 

Automatically  activates  redundant  control 
cleetronics/rnotor  driver  and  motor  in  event 
ot  loss  ol  dcspin  control 

No  single-point  futures  in  thrust  ei  opera  I  ions 
Automatic  fault  detection  and  ground  alerting 
Redundant  elements  to  unit  level 

Receiver  time  out 

Watch  dog  timers 

Onboard 

software 

None 

Ground 

a«ob.!od 

Allow  ground  intervention  for  failure  analysis 
and  switching 

Redundant  switching  foi  battery  charge  rates  and 
battery  reconditioning 

Redundancy  management  on  ground 

2.  Navigation  spacecraft.  The  Global  Positioning  System 
(GPS)  satellite  is  a  3-axis  stabilized,  semisyncbronous  (12-hour 
orbit)  navigation  satellite.  It  will  enable  a  user  to  accurately 
determine  his  position,  velocity,  and  time.  When  fully  opera¬ 
tional,  there  will  be  18  satellites  on  orbit.  To  date  six  have 
been  launched,  the  first  on  February  22,  1977.  Each  satellite  is 
designed  for  a  mean  mission  duration  of  5  years;  the  fault¬ 
handling  characteristics  are  given  in  Table  3. 


Table  3.  Global  Positioning  System  fault- handling  characteristics 


fault-tolerant  lx 

attribute  Desenptton 


Onboard 

hardware 


Onboard 

software 


(hound 

assisted 


l  ull  redundancy  except  where  impractical 
<e.g.,  structure) 

Multiple  redundancy  in  critical  subassemblies 
(o.g..  triply  redundant  atomic  clocks) 
Automatic  detection  and  isolation 

IJectrical  shorts,  attitude  loss  handled  by 
load  shedding 

Jet  runaway  handled  by  watchdog  logic 
Automatic  detection  and  correction  at  unit  level 
tor  system  performance  degradation  failures 
Earth  sensor 

Control  Electronics  Assembly  power  supplies 
Masking  of  solar  array  system  performance 
degradation  failures 

Automatic  Sun  reacquisition  from  eclipse 


No  spacecraft  bus  software 


Allow  ground  intervention  for  tailure  analysis  and 
switching 

Redundancy  management  on  ground 
Battery  reconditioning 
Routine  health  and  status  monitoring 
Ephemeris  and  time  update 
Magnetic  momentum  dump 


3.  Meteorological  spacecraft.  Defense  Meteorological  Satel¬ 
lite  Program  (DMSP)  Block  5D  spacecraft  are  3-axis  stabilized 
and  operate  in  a  Sun-synchronous  polar  orbit  at  830  km 
(450  nmi).  Tire  Block  5D  spacecraft  have  a  2-year  design  life; 
the  first  was  launched  September  1 1.  197b.  The  fault -handling 
characteristics  of  these  satellites  are  given  in  Table  4. 


4.  Multimission  spacecraft.  The  Multimission  Modular 
Spacecraft  is  3-axis  stabilized  and  can  be  used  for  various 
mission  classes.  It  can  be  used  in  orbital  altitudes  from  low- 
Earth  to  geosynchronous.  The  first  launch  was  February  14. 
1980.  It  has  a  2-year  mission  lifetime,  and  is  capable  of  being 
resupplied  by  the  shuttle.  Its  fault-handling  characteristics 
are  given  in  Table  5. 
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Table  4.  Defense  Meteorological  Satellite  Program 
fault-handling  characteristics 


Table  5.  Multimission  Modular  Spacecraft 
fault-handling  characteristics 


fault-tolerant 

,  ,  ,  Description 

attribute  * 


Ta'jlt-tolerant 

attribute 


Description 


Onboard 

hardware 


Onboard 

software 


Ground 

assisted 


Hardware  Watchdog  timer  requires  periodic 
response,  protects  against  loss  of  power  and 
clock  or  system  lock-up 
Hardware  testing  of  parity ,  illegal  instructions, 
and  memory  addresses  t computer 
self-tests  l 

Physical  and  functional  redundance  in 
subsystems 

Hardware  detection  switching  in  power 
subsystem 

Redundant  central  processing  units 

Protective  software  in  powei  subs\  stein 
Solar  array  drive  control 
Battery  state  ot  change,  low  voltage. 

temperature  checks 
Load  shedding  in  eve*  t  of  fault 
Software  response  to  c  ors  tested  in  above 
Spare  memory  with  special  sof  tware  packages 
to  anticipate  recovery  after  memory  failures 
Detection/ switching  m  subsv  stems  other  than 
power 

Allow  ground  intervention  tot  failure  analysis 
and  switching 

Special  onboard  processor  lest,  memoiy 
patterns.  J /agnostic  msirm  non  resj 
Reprogram  computers 
Data  trend  analysis 


Onboard 

hardware 


On  boa  id 
so!  tw  .ue 


(•round 

assisted 


Block  redundancy 

No  credible  single-point  failures  in  space¬ 
craft  bus 

Computer  tailurc  detections  (watchdog 
timers)  in  the  attitude  control,  commu¬ 
nications.  and  power  modules:  reconfig¬ 
ures  spacecraft  to  power  sate  Sun-pointing 
mode  using  analog  backup  system 

Lndcrvoltagc  detection  and  sating 

Bjttery  state-ul-eharge  calculations 

Computer  sell -lest 

Spacecraft  oft -pointing  detection  and  sal  ine 

Telemetry  data  quality  checks 

Internal  validity  checks  for  attitude  deter¬ 
mination  and  control  software 

Monitor  health  and  safely  of  prude  termined 
payload  instruments  with  onboard 
sating  actions 

Allow  ground  mfenenfton  )o/  failure  analysis 
and  switching 

Power  regulator  I  allure  detection  and 
tones live  action 

Redundancy  management  on  ground 


Table  6.  Voyager  fault-handling  characteristics 


5.  Planetary  exploration  spacecraft  T he  hn>  T-axi.s  slabil- 
i/ed  Voyager  spacecraft. laun«'hcd  August  20  ami  September  5. 

are  designed  to  explore  the  planets  Jupiter  and  Saturn 
bach  spacecraft  was  designed  for  a  4-year  mission  lifetime, 
all  hough  each  has  enough  expendables  for  possible  extended 
missions.  Table  b  lists  Voyagefs  fault-handling  characteristics 


I  .ailt-tolcrant 
attribute 


t  )nbo  rd 

h.udw  ik 


B.  Fault-Handling  Design  Features  01  Spacecraft 

Several  observations  can  be  made  from  the  fault-handling 
characteristics  ot  the  spacecraft  presented.  The  spacecraft 
typically  employ  block  and  functional  redundancy  tor  high 
reliability,  as  well  as  watchdog  timers,  cross-strapping,  and  Dniw.-m 

'.witching  networks  tor  fault  protection  and  self-preservation 
In  general,  there  are  no  credible  single-point  lailmev  The 
ground-assisted  features  include  such  capabilities  asephenicns 
arid  time  updates,  trend  analysis,  and  mission  recontigui.it ion 
Redundancy  management  is  done  mostly  on  the  gmund.  and 
in  all  cases  th°  ground  has  an  override  capahiltrv 

Ground 

assisted 

Block  redundancy  employs  complete,  identical,  extia 
components  that  can  take  over  in  the  event  of  a  component  _ 


Description 


<  Kertcinpei.mire  protect  ion  Jor  payload 
instruments 

X"  significant  ‘'ingle-point  failure'. 

Bl.u  k  and  functional  redundancy 

CompiUcr  n'lMcsi 

Nonvolatile  memory  )<u  Computer  Command 
Sub>\  stem  and  Attitude  and  Articulation 
t  ontiol  Subsystem 
t  ndervoltaee  protection 

Rarity  ami  t ode  checks 
Restores  command  link 
Switches  processors 
Switches  power  elements 
Sw  itches  Suit  star  sensors 
Sw itches  thrusters /p| umbmg 
Reprogrammable 
I  vent  inning  and  event  counting 
Retry  tot  some  data  transmission  ertors 
Block  parity  validation  of ^  command 
sequences 

Sw  itching  ot  redundant  components  with 
noncutaslTophic  failure  modes 
Alternate  opera  ling  modes 
I  rend  analysis  and  calibrations 


8 


failure.  There  are  several  levels  at  which  block  redundancy  can 
he  applied.  In  ascending  order  these  are  the  element,  func¬ 
tional  unit,  functional  string,  subsystem,  and  system  levels. 

Functional  redundancy,  on  the  other  hand,  does  not 
employ  identical  components,  but  instead  performs  near))  the 
same  functions  using  alternate  system  or  subsystem  configura¬ 
tions.  typically  controlled  from  the  ground.  Functional 
redundancy  has  an  advantage  over  block  redundancy  in  that  it 
helps  avoid  systematic  design  errors;  however,  it  generally 
does  not  possess  equal  performance  capability. 

In  the  event  of  a  failuie.  the  operating  philosophy  for  the 
spacecraft  systems  has  been  to  rely  on  ground  interaction  to 
restore  successful  operations.  This  has  given  rise  to  the  safe- 
hold  mode  in  which  the  spacecraft  is  autonomously  switched 
to  a  benign  state  until  ground  interactions  restore  operation. 
Tlie  ground  action  typically  involves  fault  detection  through 
analysis,  commanded  switching  to  isolate  t ho  defective  ele¬ 
ment.  and  finally  recovery  procedures  through  reconfiguration 
of  available  resources. 

C.  Current  Design  Methodologies 

Methodologies  have  been  defined  to  include  procurement 
management  policies  and  design  development  procedures.  The 
procmement/management  policies  structure  the  development 
process  through  the  use  of  formalized  management  lepnrts. 
design  reviews,  and  audits.  Design. development  procedures 
refer  to  t he  collective  set  of  design  tools  and  test  and  \alida- 
tion  procedures  that  are  employed  during  the  development 
process. 

iV-.ign  tools  are  employed  to  evaluate  the  adequacy  ol  a 
p?opov\l  design  pilot  to  a  commitment  for  fabrication.  Such 
tools  mciude  simulation,  emulation,  and  reliability  analysis 
lecluiMues  (denned  by  MU -I il)BK  .' I  ' Testing  procedmes 
strive  to  show  that  the  spacecraft  operates  pet  the  design 
intent  they  should  identity  t .ml i \  components  and  eimis  m 
manutactuimg  Validation  programs,  on  the  other  hand,  sliive 
to  inv.ue  the  aeteemem  ol  the  system  realization  with  the 
swiem  specification.  Tins  includes  validation  ot  peifo:  malice, 
reliability,  and  environmental  requirements 


II.  Fault-Tolerant  Computing 

An  assessment  of  the  state  of  the  art  m  fault-tolerant 
computing  was  undertaken  as  part  »>|  the  ASM  study  for  two 
important  reasons,  f  irst,  it  is  a  technology  that  has  been  under 
investigation  tor  over  twenty  years,  and  that  has  resulted  in 
i ho  development  of  several  autonomously  maintained  systems 
(e.g  sell -repairing  computer  systems)  Second,  it  appears  that 


onboard  fault-tolerant  computers  will  be  required  to  act  as  the 
automated  lepairman  for  ASM  spacecraft. 

A  number  of  taiilt-tolerant  computers  have  already  been 
constructed  and  used.  The  largest  application  is  j»  telephone 
switching  systems.  Most  modern  switching  offices  arc  autono¬ 
mously  maintained  systems  The  resident  computer  is  capable 
of  detecting  faults  within  itself  and  in  surrounding  equipment, 
replacing  the  faulty  equipment,  and  continuing  normal  service 
(Ref.  If  Computers  with  varying  degrees  ot  autonomous 
self-repair  have  been  used  in  other  commercial  applications 
I  xamples  are  the  Plunbus  Mult  ip  cessoi  tor  vommunk  ations 
systems,  and  the  Tandem  Computer  Systems  olten  used  lor 
financial  transactions  (Ref.  2).  In  aerospace  s>  sterns,  example** 
ol  fault-tolerant  c»  mpunng  can  be  Jound  in  commercial 
airplanes,  the  Space  Shuttle,  and  in  the  Saturn  V  guidance 
computer  (Ref.  3).  Thus  there  exists  a  large  body  ot  design 
experience  in  the  development  of  ijuli-lolerani  li  e  .  aut*-no 
mouslv  sell -maintained  >  computing  systems  tot  a  variety  ot 
applications. 

Although  two  breadboard  systems  have  been  constituted 
and  tested,  and  a  third  is  under  development,  fault -tolerant 
computing  has  not  been  used  on  current  spacecraft  Two  goals 
of  the  Fault  Tolerant  Technology  Working  ('roup  were  to 
provide  a  state-of-the-art  assessment  id  tault  tolerant  comput 
mg  jo  the  spacecraft  sy  stems  technologists,  and  to  evaluate 
piohlems  and  prospects  tor  employing  tault -tolerant  comput¬ 
ing  in  spacecraft  flight  systems.  Fach  inembei  ot  the  working 
group  is  actively  involved  in  the  development  ot  a  state-ot-thc- 
art.  fault-tolerant  computing  system,  and  each  made  presenta¬ 
tions  on  their  systems. 

Seven  tault -tolerant  computing  systems  were  presented. 
They  are  catago-i/ed  into  three  groups:  ( 1  )  onboard  spacecraft 
computers.  avionics  computers,  and  (of  commercM) 
computers. 


A.  Onboard  Spacecraft  Computers 

Two  computer  systems  were  presented,  the  Fault -Tolerant 
Space  borne  Computer  and  the  Building  Block  Fault -Tolerant 
Computer. 

1  Fault  Tolerant  Spaceborne  Computer  The  Fault 
Tolerant  Spaceborne  Computer  is  a  general-purpose  computer, 
designed  to  Air  Force  specifications  of  high  throughput  and  a 
*>5'"  probability  of  surviving  (unattended  and  without  degra¬ 
dation  of  performance)  for  5  to  7  years.  This  machine  is  cap¬ 
able  ot  sell -reconfiguration  and  resumption  of  computations 
following  internal  component  failures,  power  transients,  ami 
radiation  events. 
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The  Fault-Tolerant  Spaceborne  Computer  is  in  an  advanced 
state  of  development.  A  laboratory  breadboard  has  been 
constructed  and  the  fault-tolerance  features  verified  by  exper¬ 
imental  testing  (e.g..  insertion  of  faults  and  verifying  proper 
recovery).  The  machine  is  based  on  complementary  metal- 
oxide  semiconducted  silicon  on  sapphire  LSI  technology.  It 
is  not  available  for  flight  use  due  to  an  inability  to  ob»ain 
radiation-hardened  (1000  gate/chip)  integrated  circuits 
(Ref.  4). 

2  Building  Block  Fault-Tolerant  Computer  The  Building 
Block  Fault-Tolerant  Computer  is  a  fault-tolerant  distributed 
computer  system  architecture.  It  is  aimed  at  spacecraft  systems 
tli at  employ  a  large  number  of  microcomputers  embedded  in 
various  subsystems,  and  is  an  outgrowth  of  the  Unified  Data 
System  architecture  developed  at  JPL  (Ref.  5)  This  architec¬ 
ture  uses  a  small  set  of  standard  building  block  circuits  that 
allow  existing  microprocessors  and  memories  to  he  connected 
together  into  fault-tolerant  disiiihutcd  computer  systems.  The 
building  blocks  connect  the  central  processing  unit  and  the 
random  access  memory  to  form  self-checking  computer 
modules  that  can  detect  then  own  internal  faults  during 
normal  operation.  The  sell  checking  computer  modules 
contain  interlaces  to  a  set  ot  redundant  intercommunication 
buses  md  can  he  connected  into  a  network  in  which  spare 
computers  are  employed  tor  fault  recovery. 

\  breadboard  ol  the  Building  Block  Fault-Tolerant  Com¬ 
pute  is  currentK  being  developed,  and  it  is  expected  that  it 
will  >e  vumpleted  and  centred  in  Flight  availability  wili 

require  the  subsequent  development  of  two  VLSI  and  four  LSI 
miegiated  circuits,  and  ill  lake  ,m  additional  two  or  thiee 
sears  The  problem  »»?  obtaining  ladiaiion  hard  parts  is  com¬ 
mon  to  both  the  Fault  Tolerant  Spaceborne  Computer  and  the 
Building  Blo^k  Fault •  L 'leant  Computer  programs. 

B.  Fault- Tolerant  Avionics  Computers 

I  wo  .ivionu  -  *.o;npuieis  weu*  piesented  These  machines 
have  been  developed  b\  NASA  tor  control  »>t  tutum  tuel 
etlkient  aiuuti  th.ii  will  be  dvnamicalK  unstable.  1  xtiemelv 
lngli  Teli.ib||n\  is  ie>iaiicd  sirue  lives  ma\  depend  on  emmet 
^■mpuVi  upeiatioi'  I  bus  a  r c  1  u» t m  1 1 1 >  "I  0  OOOOOOOOO  js 
icquued  !oi  eves  l-iiiour  flight  im>snm  These  avionics 
.■•mputris  are  not  dm\  Ms  applicable  to  spacecialt.  Wentht 
i»  wer  and  volume  gie.itlv  y  eed  what  can  he  mpported  hv  a 
sp  i'. i.iit  Ihe>  ate  .iis* ■  designed  io  allow  human  mjinicn- 
aike  ’ter  ever\  iU-liour  tliglit  when  the  plane  is  on  the 
giourd  a  vondition  not  experienced  In  space*.  ijM 

Ihe  two  avionics  computers  are  designated  Fault-Tolerant 
Multiprocessor  and  Software  Implemented  Fault  Tolerance. 


Both  have  been  developed  as  breadboard  systems  and  are 
currently  under  test.  Though  not  immediately  applicable  to 
spacecraft,  many  of  the  techniques  and  insights  developed  in 
their  design  will  be  applicable  to  long-term  research  into  future 
ASM  systems.  These  machines  are  summarized  below. 

1.  Fault-Tolerant  Multiprocessor.  The  Fault-Tolerant 
Multiprocessor  is  intended  for  use  as  one  of  at  least  two 
central  computers  in  a  redundant  distributed  digital  system 
designed  to  serve  as  a  highly  survivable  avionics  system.  The 
design  is  based  on  independent  processor-cache  memory 
modules  and  common  memory  modules  that  communicate  via 
redundant  serial  buses.  All  information  processing  and  trans¬ 
mission  is  conducted  in  triplicate  so  that  local  voters  in  each 
module  can  correct  errors.  Modules  can  be  retired  and/or 
reassigned  in  any  configuration.  Reconfiguration  is  carried  out 
routinely  from  second  to  se<  ond  to  search  for  latent  faults  in 
the  voting  and  reconfiguration  elements.  Job  assignments 
are  all  made  on  a  floating  Ir’sis.  so  that  any  processor  tiiad  is 
eligible  to  execute  any  job  step.  The  core  software  in  the 
Fault-Tolerant  Multiprocessor  will  handle  all  lault  detection, 
diagnosis,  and  recovers  in  such  a  was  that  applications  pro¬ 
grams  do  not  need  to  be  involved  (Ref.  0). 

2.  Softsvare  Implemented  Fault  Tolerance.  Software  Imple¬ 
mented  Fault  Tolerance  is  an  ultrareliable  computer  for 
critical  aiicruft  control  applications  that  achieves  fault  toler¬ 
ance  by  the  replication  of  tasks  among  processing  units.  The 
main  processing  units  are  off-the-shelf  minicomputers.  Fault 
isolation  is  achieved  by  using  an  individually -buffered,  serial 
data  [ink  between  each  ptoeessur  pair  for  all  processors.  Frror 
detection  and  analssis  and  system  reconfiguration  are  per- 
toimed  by  software.  Iterative  tasks  are  redundantly  executed, 
and  the  icsiilts  of  each  iteration  are  voted  upon  before  being 
used.  ITuis.  ;m\  single  failure  in  a  processing  unit  or  Inis 
can  he  tolerated  with  triplication  or  qumtuplication  ot  tasks, 
and  subsequent  {’dilutes  can  be  toleiated  alter  reconfiguiation. 
The  Software  Implemented  Fault  Tolerance  software  is  luglilx 
structured  and  is  formally  specified  using  the  SRI -developed 
SIM  (  I A  L  language  (Ret.  7) 

C.  Fault-Tolerant  Commercial  Computers 

Miree  tault-t**leiant  computing  projects  at  Carnegie  Mellon 
l  niversit)  weie  piesented.  These  systems  use  DFC  minicom¬ 
puters  and  are  aimed  at  commercial  applications  Though  not 
direct l>  applicable  tv)  spacecraft  systems,  some  of  the  insights 
gamed  m  then  design  are  applicable  to  ASM  research.  These 
machines,  designated  Canmp,  Cm*,  and  C.vmp,  aic  Minimal- 
i/ed  below  . 

I  C.nimp,  a  niultiminiprocessor.  C.mmp  is  a  canonical 
multiprocessor  system  with  a  16  X  1(>  crosspoint  switch.  Up  to 
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lb  DEC  PDP- 11/40  processors  may  be  connected  to  the 
processor  ports  on  the  switch.  The  16  memory  ports  provide 
an  address  space  in  shared  memory  of  32  Mbytes.  Any  pro¬ 
cessor  can  access  any  of  the  16  memory  ports  for  memory 
accesses.  The  entire  set  of  processors  may  communicate  via  an 
imerprocessor  bus  that  allows  interprocessor  interrupts  at  one 
of  four  priority  levels,  continuously  broadcasts  a  60-bit 
nonrepeating  clock  value,  and  allows  any  processor  to  HALT. 
START,  or  C  ONTINUE  any  other  processor  (Ref.  <S). 

2.  Cm*,  a  modular  multimicroprocessor.  Cm*  is  a  modular 
multiprocessor  system  based  on  the  LSI-1 1  processor.  Each 
computer  module  is  connected  via  an  interface  to  an  intelli¬ 
gent  cluster  controller.  The  clusters  of  computer  modules  can 
be  interconnected  via  intercluster  buses.  Each  computer  mod¬ 
ule  can  share  memory  with  any  other  computer  module  in  the 
network  through  routing  tables  in  the  cluster  controller 
(Ret.  M. 

3  C.vmp,  a  voted  multiprocessor.  C'.vmp  may  best  he 
dewiihed  as  a  multiprocessor  system  capable  of  fault-tolerant 
operation.  It  consists  of  three  separate  LSI-1  1  microcomputers, 
e.wii  with  ns  own  memory  and  peripherals.  They  may  run 
independently  as  three  separate  computers  communicating 
through  parallel  line  units,  or  they  may  be  switched  into  what 
is  termed  voting  mode  under  manual  or  program  control  to 
torm  a  triplicated  LSI-1  1.  This  form  ot  iiiplc-modidm  redun¬ 
dance  allows  the  voted  multiprocessor  to  continue  operating 
under  the  s/ruation  where  any  one  out  of  three  copies  of  any 
orpheafed  element  suiters  a  hard  taduie  (Ret.  K). 


III.  State-of-the-Art  Technology  Assessment 

I  v-  In  «*.  ;i<‘n  an  a' seamen’  will  be  made  of  the  applic- 
a1,  1.5>  •  !  ■  1 1 t on i  spacecraft  and  faith -tolerant  computer 

m, im*  ?■«  m  ASM-enhaived  'paceitall  In  genet  al.  design 
!cai,i;es  v.  :d  need  to  ht-  added  to  the  spaceciatl  to  accomplish 
the  new  i mu ti<  ins  'dictated  *w  ASM.  The  procurement, 
maiiaeement  policies  are  considered  adequate  loi  ASM.  but 
new  ‘design  rmls.  reliability  techniques.  and  test- validation 
pi  *  iv  edufes  v.  ii!  *■.“  required 

A.  Spacecraft  Technology  Assessment 

V  iii'l:  .iteu  in  the  ifonuiu  rmn.  ASM  consists  of  space* 
v  i.it'  k'Nicn  .  fh  t!  i.ih.  f.fie  Enlures  and  that  iccjuuc  no  ground 
v"fif  r  i  mter.it  :i"ii  i-*i  extended  periods  of  time.  The  follow¬ 
ing  .inu’s a: lent  ot  current  technology  is  given  against  these 
at !  nbtiies 

J  Design  features  In  each  of  the  presentations  there  were 
several  meihods  ot  tauli  detection,  isolation,  and  iceovery  that 


were  common  to  all  the  spacecraft.  The  methods  utilized  in 
the  design  and  implementation  have  evolved  in  parallel  with 
the  spacecraft  requirements.  As  requirements  for  long  life  and 
high  reliability  have  become  more  stringent,  specialized 
functions  have  evolved,  with  satisfactory  in-flight  experience 
serving  as  the  basis  for  broad  acceptance.  Typical  of  the 
specialized  techniques  employed  by  spacecraft  to  protect 
against  specific  fault  classes  are:  cross-strapping,  voters,  watch¬ 
dog  timers,  parity  cheeks,  data  coding,  counters,  and  switching 
networks.  These  fault-handling  techniques  pertain  generally  to 
subsystems.  At  the  system  level,  about  all  that  is  currently 
done  in  a  fault  situation  is  to  put  the  spacecraft  in  a  safe-hold 
mode  to  await  ground-operator  command.  It  is  the  inclusion 
ot  onboard  detection,  isolation,  and  recovery  mechanisms  for 
the  purpose  of  reducing  all  ground  interaction  that  is  the 
distinguishing  characteristic  of  ASM. 

a.  Detection  mechanisms.  Present  spacecraft  design  tech¬ 
niques  rely  on  parametric  data  telemetered  to  ground 
operators  for  fault  detection.  Generally,  faults  are  inferred 
from  the  nonreal-time  analysis  of  such  data.  However.  ASM 
requires  the  timely  detection  of  faults  by  either  direct  para¬ 
metric  measurement  or  incipient  fault  prediction  using  direct 
measurement  and  onboard  trend  analysis  techniques.  Because 
of  mass  and  power  constraints,  measurement  technology 
becomes  a  leading  technology  driver.  More  extensive  use  of 
watchdog  timers,  parity  checks,  error-coding  schemes,  and 
counters  is  anticipated.  Concerns  about  the  integrity  of 
detection  mechanisms,  utilizing  special  test  routines  and  or 
additional  detection  mechanisms  must  also  he  resolved. 

/>.  Isolation  mechanisms.  Extremely  high  reliability  switch* 
mg  techniques  dominate  fault  isolation  strategies,  which 
involve  the  ability  to  remove  faults  components  from  the 
system  prior  io  reestablishing  a  “fault-free".  fully  operational 
confieuiatioii.  At  issue  is  the  reliability  ot  the  switching 
mechanisms  themselves.  Redundant  switching  strategies, 
powei  contiol.  ,utd  special  (es(  routines  to  assess  switch 
integrity  during  latent  intervals  are  required. 

t  Recovery  nia  hanisms.  Recovers  mechanisms  tend  to 
center  upon  issues  of  resource  management  jnd  techniques  to 
maximize  system  peMonnance  subsequent  to  faults.  As  such. 
tlu*>  represent  ;j  system  atitibute.  whereas  detection  and 
isolation  mechanisms  aie  chaiacteii/ed  as  subsystem  attributes. 
A  system-level  view  of  the  available  spacecraft  resouices 
will  be  needed,  and  so  system  irade-olt  studies  st living  to 
minimize  cost  (mass,  volume,  power)  and  maximize  lecovery 
potential  Irom  Emits  are  requited. 

2.  Spacecraft  methodologies.  In  general,  the  procurement 
management  policies  have  been  considcicd  adequate  by  the 
study  participants,  however,  new  design  procedures  are  antici- 
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pated.  The  following  discussion  focuses  on  the  need  for  new 
design  tools  and  new  test  and  validation  procedures. 

a, .  Design  tools.  Simulators  and  emulators  will  be  required 
to  provide  relative  assessments  of  the  design  and  to  assist  in 
trade-off  evaluations.  Present  reliability  methods,  however,  as 
defined  by  Mil  -HDBK-217  may  not  be  directly  applicable  to 
ASM.  Areas  requiring  further  study  include: 

(1)  Software  and  firmware  reliability.  The  problem  in¬ 
creases  with  the  complexity  of  the  software,  and  total 
project  orientation  is  needed  for  success. 

(2)  Predictive  methodology  for  transient  failure  analysis. 
Test  data  on  commercial  computer  systems  presented 
during  this  study  indicate  that  as  many  as  50' <  to  00' 7 
of  repotted  failures  result  from  transient  faults. 

/>.  Testing.  The  present  testing  techniques  have  been  shown 
to  he  adequate  for  current  spacecraft.  For  an  ASM  spacecraft, 
however,  new  testing  methods  may  be  requited  because 
( 1 )  testing  of  ASM  functions  must  be  done  at  each  step  in  the 
integration  process;  (2)  new  onboard  capabilities  may  requite 
new  lest  equipment;  and  (2)  the  possibility  of  ASM  masking  a 
failure  prior  to  launch  must  be  detected. 

r.  \'a filiation.  A  major  element  of  validation,  specifically 
relevant  to  ASM.  is  reliability  validation.  As  noted  at  a  NASA 
conference  on  validation  methods  research  tor  fault -toleiaut 
avionics  and  contiol  systems  (Ret.  9): 

S  A  traditional  approach  to  reliability  validation  is 
the  lifetesting  method  in  which  one  takes  n 
statistically  identical  copies  of  the  system  under 
test  and  tetmmates  the  test  after  r  (1  <  r  ^  n) 
systems  have  failed.  I -sing  the  accumulated  lime 
on  test,  one  can  derive  a  point  estimate  and  con¬ 
fidence  intervals  tor  Uk  mean  life  of  the  system. 

These  statistical  techniques  also  allow  one  to  cal¬ 
culate  confidence  intervals  for  system  reliability 
tot  any  given  mission  tune.” 

** . the  ntimbet  of  systems  required  l o  be  put 

under  test  increases  monotonically  with  the  reli¬ 
ability  of  the  system  being  tested.  Furthermore. 

(lie  validation  problem  is  compounded  because  the 
cost  of  an  individual  copy  of  the  system  also 
increases  remarkably  with  its  reliability.” 

...  applying  traditional  lileiesling  techniques 
implies  unreasonably  high  validation  costs.” 

Tlte  conclusion  of  the  NASA  workshop  is  that  a  new  valida¬ 
tion  methodology  is  required  for  fault-tolerant  avionics  and 


control  systems.  This  conclusion  is  also  appropriate  for  long- 
lived.  highly  reliable  spacecraft  systems. 

B.  Fault-Tolerant  Computing  Technology  Assessment 

The  following  conclusions  summarize  the  slate  of  tlte  art 
in  fault-tolerant  onboard  computers,  and  the  applicability  of 
extending  the  methodology  of  fault -tolerant  computing  to 
ASM. 

1.  Machine  availability.  No  fault-tolerant  computer  are 
currently  available  for  use  on  ASM  spacecraft.  The  An  Force's 
Fault- Tolerant  Spaceborne  Computet  is  the  most  viable  candi¬ 
date  bn  use  in  a  P>S5  ASM  demonstration,  since  it  is  the  only 
fault-tolerant  onhouid  processor  in  an  advanced  state  of  devel¬ 
opment.  A  hieadhourd  lias  been  constructed  and  verified.  Fite 
niajot  obstacle  to  its  use  is  the  development  of  low-powei. 
radiation-haidened  l  SI.  This  is  an  enabling  technology  tot  all 
advanced  digital  systems  in  l  SAl:  spaceciaft  and  is  being 
treated  as  a  problem  of  high  priority  and  urgency. 

The  Fault-1  oleiant  Spaceborne  Computer  may  be  ham¬ 
pered.  however,  because  it  is  implemented  as  a  si/igiv  uni¬ 
processor.  It  is  expected  that  future  spacecraft  architect mes 
will  tend  toward  a  r  roli  feral  ion  of  small  microcomputois  in 
a  variety  ot  control  and  payload  subsystems.  Fault  tolerance 
will  need  to  be  distributed  thioughout  these  distributed 
architectures  (e.g..  special  fault-detection  hardware  will  be 
requited  in  each  small  subsystem  computer),  and  a  hierarchy 
of  lecovety  mechanisms  will  be  employed.  Therefore  it  is 
impoitant  that  fault-tolerant  distributed  computing  sy stems 
be  developed  for  future  generations  of  ASM  spaceciaft.  The 
Building  Block  I'ault-Toleianl  Computer  is  a  distributed 
computing  system  being  developed  toward  that  objective.  It 
is  not  as  tar  advanced  in  development  as  is  the  Fault -Toleiant 
Spaceborne  Computei,  but  it  may  be  available  as  an  alterna¬ 
tive  flight  system  in  the  future. 

2.  Fault-tolerance  methodology.  Many  ot  the  techniques 
employed  in  fault-t oleiant  computer  design  can  he  extended 
beyond  the  computing  subsystems  to  the  ASM  spacecraft 
system.  This  has  already  been  demonstrated  to  a  considerable 
extent  ten  years  ago  m  an  ASM  study  of  tlte  NASA  Hum  mo- 
electric  Outer  Planets  Spaceciaft  (Ref.  10).  Some  ol  the  fault 
tolerant  computing  methodologies  that  can  be  appbed  to 
spaceciaft  are  listed  below: 

(1)  Careful  definitum  of  fault  set  !n  both  digital  uul 
spaceciaft  systems,  it  is  necess.uy  to  carefully  dot  me 
and  analyze  the  fault  conditions 

(2)  l'ault^!ctceti<>n  algonthn/s  Following  a  lUJclul  anal¬ 
ysis  of  Units,  it  is  necessary  to  deteimmc  the  mecha¬ 
nisms  by  which  they  are  detected.  In  both  digital  and 


nondigital  subsystems,  this  takes  the  form  of  special 
sensing  hardware  and  software. 

(3)  Fault  containment:  To  simplify  fault  recovery,  in  both 
computers  and  spacecraft,  it  is  necessary  to  design  the 
system  so  that  the  spread  of  damage  caused  by  a  fault 
is  minimized.  Whenever  possible,  it  is  advantageous 
to  detect  and  contain  faults  at  the  lowest  possible 
level. 

(4  I  Hierarchic  fault  recovery .  Fault  detection  and  recovery 
in  computers  is  done  in  a  hierarchic  fashion.  Recovery 
may  he  implemented  at  various  system  levels  depend¬ 
ing  upon  the  origin  and  severity  of  the  fault.  This  meth¬ 
odology  clearly  applies  to  spacecraft  systems  as  well. 

(5)  Reliahilit\  modeling:  Reliability  and  performance 
models  developed  tor  ijiilt-toierant  computers  are 
applicable  to  ASM  spacecraft.  The  concept  of  "cov¬ 
et  age  .  which  describes  the  effectiveness  of  the  fault 
nvotery  rnec/umsm.v  is  very  important  in  both  com¬ 
puter  and  spacecraft  systems.  F\ten>ions  ot  existing 
reliability  and  performance  models  for  computers  are 
u.ommcnded  for  spacecraft  evaluation 

IM  1  aliiiaticn  Current  work  on  the  validation  of  fault 
tolerant  comp1  tors  will  be  applicable  to  spacecraft 
systems.  Fault-tolerant  computers  and  ASM  design 
should  make  it  much  easier  to  verity  the  integrity  <u 
the  fault  recovery  mechanisms  without  insert  me  faults 
into  the  system.  Techniques  for  and  results  of  experi¬ 
mental  testing  of  fault-tolerant  computers  will  be  of 
considerable  value  to  ASM  spacecraft  engineers. 


(7)  Resource  management:  In  complex  computing  systems 
and  in  spacecraft  there  is  a  resource  management  prob¬ 
lem  associated  with  fault  recovery.  As  an  attrition  of 
resources  occurs  due  to  faults,  the  system  must  op¬ 
timally  allocate  those  resources  remaining. 


IV.  Summary  Observations 

Reduction  of  space  system  vulnerability  can  he  achieved 
by  moving  the  control  .'operation*  cemei  function''  on  hoard 
the  spacecraft.  1o  do  this,  an  autonomous  spacecraft  mainte¬ 
nance  capability  is  required  that  I))  incorporates  design 
features  that  permit  the  spjcecutt  to  tolerate  faults  and 
(2)  eliminates  the  need  for  routine  gomnd  con tact.  The  mili¬ 
tary  spacecraft  are  currently  designed  i"i  ground-controlled 
nvunterance.  and  in  terms  ot  the  ASM  capabilities  described 
above,  they  cannot  u«*w  .»utonomousl>  maintain  then  own 
health  and  weff.uc  Fhe  planetary  spacecraft  described  ate 
a  step  c!<\e:  u  ihv  c *.ii  but  are  not  there  themselves.  Thus, 
although  coi»io  p;. •nocMng  work  m  ASM  has  been  done,  u  is 
still  in  ;t'-  iO’.ukv  In  addition  to  the  enhancement  <4  the  cur¬ 
rent  capabilities  that  have  alie.uiy  been  mentioned,  the  study 
croup  lorescv'  two  maim  technological  developments  that  arc 
needed  fo  enable  ASM  These  are  (!)  a  fault-tolerant  data 
processing  system  and  (3)  an  autonomous  navigation  capa¬ 
bility  (to  reduce  the  dependence  on  the  control  operations 
center)  The  study  group  is  unanimous  m  its  assessment  that, 
with  these  developments,  the  ASM  capability  can  he  made 
available 
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The  ASM-Enhanced  System 


I.  Candidate  Design  Requirements 

(  *  UK  in  rent  with  the  stato-ot-the-ai  t  spacecraft  system  ami 
;ault-(niet ant  computer  asv'ssments.  the  study  group  defei- 
nuned  a  no!  ot  ASM  system  requirements  to  convey  ASM 
attributes.  sn  that  a  spacecraft  concept  cmild  in'  established 
I  hi-  impact  o'  these  requirements  on  ‘inure  -\n  force  space- 
mat’  v\  >toim  was  then  analyzed.  I  <>lh'wing  ate  the  candidate 
>-  'iiceptual  design  roqunemems  developed  from  this  stud) 

(1)  1//  tr>'  lorn  span  craft  faun  hed  after  March  / y.vv 

s/r./.V  ."?((/■  r//c  t.V.l/  r<  quirements  //N7r</  below  On 
ihm  date,  th.e  Depaitment  ot  Delense  would  require 
all  subsequent  spacecraft  purchased  n>  include  the 
tully  « 'peia’nuul  ASM  capabiliy 

i  Pi  I*1!  to  this  date,  it  ts  desirable  M  add  UKremental 
ASM  capabilities.  ^insistent  with  system  perfor¬ 
mance.  as  they  are  developed  ) 

I  hi  Pn  ASM  spacecraft  shall  operate  without  a  ground 
support  f  ontri'l  link  for  up  to  Whlavs  without  degra¬ 
dation  of  performance  This  is  the  essence  of  autono¬ 
mous  operations  The  spacecralt  will  function  until 
ground  support  is  available  or  desirable  from  the 
viewpoint  ot  the  ground  support  team. 


(S )  The  ASM  spacecraf  t  shall  operate  w  ith  not  more  than 
I0r ■  degradation  of  key  functions  onr  a  tf-month 
period  t\f  autonomy.  Tin-  requirement  oh.1  set  some 
sizing  cons’ taints.  such  as  data  storage,  and  require 
some  definition  oi‘  loss  of  performance.  !;  sir  esses 
the  need  tor  continuous  function  of  the  spacecraft 
on  an  “ad  hoc"  basis  if  scheduled  ground  support  is 
not  provided.  The  1  O  '  figure  is  somewhat  arbitrary; 
however,  at  the  end  of  6  months,  the  performance  of 
the  entire  sy  stem  shall  he  at  a  useful  level 

( 4  )  Pie  ASM  sthu  vc  raf  t  shall  in tt rac  7  with  the  ground 
support  segment  Jt>r  not  nn>rc  than  up  minutes  to 
per  firm  ali  required  support  fune  turns  without  per¬ 
formance  degradation  After  a  period  of  autonomy, 
it  is  requited  that  the  spacecraft  and  ground  .support 
perform  all  the  tequiied  support  functions  m  this 
window  The  t unctions  include  (a)  downlink  of  all 
stored  maintenance  histoiy  .  < b >  uplink  of  all  data 
load  (such  as  star  tables  and  ephemensh  (c|  redun¬ 
dancy  management,  and  (d)  testing.  Specification  ot 
the  duration  ot  the  support  window  is  mission 
dependent  The  mtent  would  be  an  uplink  support 
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period  approximately  the  same  as  that  required  tor 
non- ASM  spacecraft. 

[>)  ASM  shall  not  change  the  design  lifetime  of  the 
spacecraft.  The  imposition  of  the  requirement  tor 
ASM  on  a  spacecraft  development  is  in  addition  to 
mission-imposed  requirements,  particularly  the  design 
lifetime.  ASM  will  impact  the  design  methodologies. 
Such  design  issues  as  depth  of  redundancy  must  take 
into  account  the  rate  at  which  resources  are  used  up 
with  the  ASM  design  so  that  the  total  lifetime  or 
mean  mission  dilution  shall  not  be  i educed. 

(M  ASM  shall  not  change  the  performance  of  the  space 
era  ft  or  its  payload .  All  requiiements  placed  upon 
t he  spacecraft  development  tor  performance  ol 
either  spacecraft  or  payloads  shall  mu  he  affected 
ny  the  presence  ol  autonomous  spacecraft  mainte¬ 
nance.  The  spacecraft  must  he  designed  to  provide 
lih'sc  performance  lei  els  m  the  absence  ol  frequent 
ground  condo!  interaction.  Specific  additional 
spacecraft  /unctions,  such  as  navigation,  may  he 
lequued  to  meet  die  autonomy  requiiemeni.  II  so. 
the  performance  »U  those  tunciions  (e.g..  navigation 
accuracy  >  nnisi  support  non-ASM  system  peitoi- 
.nance  requirements. 

(i  l  he  ASM  spacecraft  shall  he  a  hie  to  recover  trow 
fnlurcs  that  ha ir  heen  defined  a  pram,  and  the 
pr<  'hahiittv  that  any  particular  failure  was  dt  jined  a 
nnuri  shall  he  •  *  The  ASM  functions  include 

momtoime  the  spacecraft  peilorinaiue  ! * » i  faults  and 
:'t  •  ’nlem  \v  mpuoms.  and.  m  the  presence  »*1  j  i.nrih 
identity  mg.  is«  laMm*.  .tml  implementin'.:  she  myowt. 
iu.it’  at  :’oth  an  \  ,!em  ami  Astern  levels  The  a 
nti"ii  analvsis  shall  he  Million  nth.  complete  that, 
during  die  lifetime  . M  the  spacecraft.  at  least  AS  ;  ot 
the  lailures  (e.c..  where  some  component  has  tailed) 
will  he  identified  in  tins  manner  (the  coverage  is 
*‘hs  ).  (ompouiul  lailures  wherein  multiple  symp¬ 
toms  auur  simultaneously  or  neat  simultaneously 
dining  the  defection  and  recovery  period  can  he 
exempted  from  this  requirement. 

<M  I'd/ownie  launch,  the  ASM  spa*  unit?  shall  go 
through  a  pe  riod  of  on-orlm  c  hec  kout  and  initialisa¬ 
tion  oj  the  same  duration  as  that  of  a  eomparahle 
non  ASM  spacecraft  The  autonomy  requirements 
discussed  hute  are  applied  to  the  operational  period 
of  the  spuccci.il! .  winch  is  deemed  to  begin  following 
the  on-oi hit  checkout  period  In  the  checkout  period, 
maintenance  will  he  under  mound  control,  with 
autonomous  capabilities  turned  on  or  oft  as  appro- 
pit. ite  Since  the  addition  »q  ASM  does  add  certain 


functions,  operating  modes,  and  complexities  to  the 
spacecraft,  tnese  must  also  be  checked  out  during  the 
same  period.  Following  checkout,  all  autonomy 
requirements  will  apply. 

(d)  The  spacecraft  shall  process  and  store  all  onboard 
management  data  required  f</r  ground  support .  and 
shall  telemeter  the  data  during  the  ground  support 
periods  upon  ground  command.  Jltv  capability  shall 
handle  all  necessary  data  for  6  months.  No  matter 
how  confident  designers  may  be  of  the  maintenance 
capability  ot  the  spacecraft,  it  will  he  necessary  to 
leave  a  record  for  ground  support  (an  audit  nail  | 
Without  this  information,  the  ground  support  func 
turn  cannot  evaluate  the  state  ot  the  spacecraft  and 
use  the  record  of  performance  to  extend  the  lifetime 
of  the  spaceci at l.  develop  or  implement  alternative 
operating  modes,  or  improve  future  designs. 

(10)  Ihc  ASM  spacecraft  shall  transmit  a  message  to  the 
ground  at  the  Jirst  opportunity  following  any  on¬ 
board  fault-management  activity.  Whenever  an 
incident  occurs  that  requires  maintenance  activity  in 
response  to  failure  symptoms,  it  is  important  that  the 
ground  he  given  fire  opportunit)  to  review  the  action 
and  to  verity  the  status  and  mode  of  the  spacecratt. 
Thus,  j  telemetry  message  indicating  that  some 
activity  had  taken  place  would  he  sent  to  the  ground 
ai  the  first  pass  over  an  appropriate  ground  station. 
Ibis  type  of  signal  may  he  coded  into  the  user  data 
to  trigger  an  alarm  at  the  ground  support  station. 
Scmlinu  of  the  message  Joes  not  abolish  the  obliga¬ 
tion  ot  the  spacecraft  to  retain  the  data  tor  the 
maximum  period,  and  to  continue  to  operate  m  an 
autonomous  manner  for  the  established  periods. 

(11)  Hie  ground  support  shall  be  able  to  override  ASM 
management  activities  for  the  system  and  the  sub 
systems.  While  the  ASM  spacecraft  sit  a!  I  have  the 
ability  to  pci  tot  m  redundancy  management  m  liie 
presence  of  an  apparent  fault  oi  problem,  il  is  neces¬ 
sary  that  the  ultimate  control  ovei  these  functions  he 
maintained  af  fbe  ground,  and  that  the  spacec/all 
shall  allow  for  ground  communication  that  overrides 
and  can  revet se  the  prior  decisions  of  the  ASM  i  unc¬ 
tions.  The  capability  is  necessary  so  that  the  system 
will  he  able  to  lecovei  from  such  learning  cmvc 
uncertainties  as  misdiagnosed  ptoblems  oi  design 
Maws.  In  this  way.  nontailed  components  may  he 
recycled  hack  into  t lie  configuration  inventory  o? 
lire  spacecraft  alternate  modes  of  functioning  may  he 
utilized  to  make  use  of  partial  capabilities  of  compo 
nen ts.  In  terms  of  a  hierarchical  decision  tree,  the 
ground  support  personnel  shall  occupy  the  top  level 
t»)  maxim i/.c  system  performance. 
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(12)  The  source  of  last  resort  for  fault  isolation  and  recov¬ 
ery ’  shall  he  the  ground  support.  The  ASM  spacecraft 
shah  be  designed  to  recognize  when  it  has  been 
unable  to  isolate,  remove,  and  recover  performance 
following  a  fault.  When  this  occurs,  the  spacecraft 
shall  take  action  to  protect  itself  from  self-injury  or 
dissipation  of  resources  (such  as  an  engine  firing  limit 
cycle  that  would  consume  propellant),  and  await 
ground  intervention. 

Satisfying  these  design  requirements  implies  the  movement 
ot  the  control  of  routine  maintenance  operations  from  the 
ground  to  the  spacecraft.  The  ground  segment  will  assume  a 
supervisory  role,  always  maintaining  the  ability  to  override 
ASM  actions,  but  allowing  the  spacecraft  to  initially  handle 
its  own  maintenance  functions.  The  space  segment,  on  the 
other  hand,  will  become  more  complex  due  to  the  added 
operations  it  must  perform,  including  onboard  navigation 
(eliminating  the  need  for  routine  uplink)  and  fault  detection, 
isolation,  and  recovery.  To  handle  these  added  operations,  a 
fault-tolerant  data  processing  subsystem  and  an  autonomous 
navigation  subsystem  will  be  required.  The  major  benefits  of 
ASM  would  then  include:  (1)  reduced  system  vulnerability, 
because  it  is  no  longer  dependent  upon  the  ground  station 
or  possible  incorrect  commands  by  human  operators,  and 

(2)  faster  recovery  from  failures  (seconds  instead  of  hours  or 
possibly  days)  because  recovery  procedures  would  star r 
immediately  upon  fault  detection. 


II.  Impact  on  the  Ground  and 
Space  Segments 

Some  examples  of  operations  and  maintenance  functions 
that  presently  are  accomplished  by  the  ground  segment,  but 
with  ASM  will  be  accomplished  by  the  spacecraft,  include: 

( 1  )  Altitude/pointing  commands 

(2)  Thermal  control  loop 

(3)  Power  management 

(4)  fault  mom  tor/isolation 
(>)  fault  tolerant  computation 
{(')  fault  switching 

(7)  load  switching 
(K)  Trend  analysis 

A  reduction  in  ground  control  activity  can  clearly  he  seen  It 
should  he  rememhered.  however,  that  in  its  supervisory 


capacity,  the  ground  segment  will  have  the  ultimate  authority 
and  responsibility  in  all  situations.  As  total  reduction  in 
ground  control  will  not  occui  at  one  time,  a  tiansition  phase 
will  he  required.  This  phase  will  enable  (I  )  inflight  measure¬ 
ments  of  effectiveness  foi  ASM  over  a  diverse  set  of  operating 
conditions.  (2)  the  development  of  understandable  and  pre¬ 
dictable  ASM  operations,  and  (d)  simultaneous  support  ot 
hot  It  ASM  and  non- ASM  operational  spacecraft. 

The  increase  in  spacecralt  autonomy  will  mean  an  increase 
in  the  complexity  of  the  spacecraft  While  this  inc lease  in  com¬ 
plexity  must  not  introduce  catastrophic  failures  oi  i educe  me 
payload  pertomunce.  it  will  tend  to  increase  the  spaceciait's 
mass,  power  consumption,  and  total  cost.  Gnen  the  mim\ 
group’s  knowledge  of  cut  tent  and  projected  technology  .  the 
following  hemistic  estimates  were  established  as  reasonable 
design  goals  tor  an  ASM-enlianced  spacecraft. 

Power  consumption:  ASM*.  !(J'*  ot  total 

Mass  impact:  ASM  ^  5  -  ot  total 

Cost  impact:  ASM  ^  10  :  ot  life-cycle 

Cost 

III.  A  Hierarchical  Description  of  the 
Space  Segment 

The  following  sections  describe  what  the  study  p.u ttcipants 
believe  will  he  t lie  impact  of  ASM  on  a  generalized  spacecralt 
system,  in  these  descriptions,  the  following  assumptions  have 
been  made. 

(1)  The  ASM  requirement  is  added  to  a  new  spacecialt 
before  design. 

(2)  ASM  technologies  will  be  available. 

(4)  Payload  is  treated  as  a  subsy  stem,  except  for  usei  data 
flow. 

(4)  As  long  as  mission  objectives  are  met.  normal  space¬ 
craft  functions  may  be  interrupted  dining  cei tain  fault 
rccovc ry  procedures . 

A.  System  Architecture 

System  ai  chi  lecture  evolves  tiom  the  mission  i  equipments, 
and  includes  the  hardware  organization,  data  flow  cluiactens- 
Hcs.  and  (it  a  digital  system)  the  hierarchical  operating  s\ stem. 
The  system  must  judiciously  allocate  the  available  resources 
and.  upon  command,  must  report  all  ASM  actions  (including 
parametric  data)  to  the  control  opetations  ccntci.  Finally,  it 
must  also  uisine  its  own  integiity  (thiough  self-diagnosis)  so 
that  mconect  actions  ami  ground  system  lock-out  modes  aie 
eliminated. 
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A/i  example  of  a  system  architecture  that  could  be  used  lor 
ASM  is  shown  in  Fig.  3.  This  is  characterized  by  both  distrib¬ 
uted  and  central  processing  system  attributes.  Efficient  man¬ 
agement  of  the  spacecraft  resources  based  upon  prespecified 
algorithms  require  centralization  of  high-level  decision  making. 
This  would  be  accomplished  by  a  fault-tolerant  processor, 
serving  as  the  spacecraft  central  controller,  augmented  by 
processors  located  in  each  of  the  subsystems  as  appropriate. 
In  addition  to  the  new  subsystems  already  mentioned,  t lie 
architecture  should  also  accommodate  additional  mission- 
unique  subsystems. 

The  system  architecture  example  described  above  is  one  of 
several  possible  architectures  for  an  ASM  spacecraft.  While  a 
detailed  investigation  of  the  various  architectures  was  not  a 
pari  of  this  study,  the  participants  believe  that  such  an  effort 


should  be  undertaken  as  one  of  the  first  tasks  nl  an  ASM 
development  program. 

Whichever  architectuie  is  chosen,  the  stud>  group  believes 
that  a  “layered*’  fault  protection  scheme  should  he  used, 
enabling  fault  containment  at  the  lowest  possible  level  to 
minimize  subsystem  interdependencies  resulting  from  fault 
propagation  (including  data  contamination).  Ibis  Jault  pro- 
lection  scheme  is  illustrated  in  Fig  4  In  this  scheme,  individ¬ 
ual  subsystems,  undei  system  control,  will  diagnose  local 
failures  and  take  corrective  action.  Ambiguous  problems  result¬ 
ing  from  failures  within  the  interfaces  between  subsystems 
will  require  diagnostic  loutines  and  hardwaie  to  pin-point  the 
failure.  Some  umesolvcd  system  issues  include  the  problems  of 
transients,  false  failure  alarms,  multiple  faults,  and  tauits 
within  the  fault-tolerant  computing  system.  Once  the  system 
has  been  designed,  test  and  validation  procedures  must  he 
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‘Layered”  architecture  of  fault  processing 


formulated.  Finally,  there  should  be  a  demonstration  program 
showing  that  the  requirements  for  ASM  are  met  without  com¬ 
promising  either  the  mission  lifetime  or  payload  performance. 


B.  Subsystem  Impact 

ASM  will  atfect  the  traditional  subsystems  (attitude  and 
articulation  control,  power,  telemetry  and  data  handling, 
payload,  communications,  propulsion,  and  thermal  control) 
by  requiring  that  they  add  the  capability  of  diagnosing  and 
handling  their  own  faults.  The  conceptual  design  requirements 
imposed  on  the  ASM  spacecraft,  however,  necessitate  the 
potential  addition  of  two  new  subsystems.  These  include  a 
fault-tolerant  data  processing  subsystem  and  an  autonomous 
navigation  subsystem. 

Tire  need  to  integrate  independent  subsystems  with  indi¬ 
vidual  processing  requirements  into  a  control  hieraichy  for  the 
purpose  of  managing  and  reporting  fault  -protect  ion  leads  to  a 
requirement  tor  a  fault-tolerant  data  processing  subsystem. 
Because  of  the  potential  for  power-interrupt  failure  modes, 
this  subsystem  must  include  limited  nonvolatile  backup  mem¬ 
ory  resources  for  selected  critical  program  and  data  storage. 

Tire  requirement  for  six  months  of  unattended  operations 
necessitates  an  autonomous  navigation  capability .  The  prob¬ 
lems  of  vehicle  position  and  velocity  are  dependent  upon  mis¬ 
sion  requirements  for  attitude  control  and  pointing.  It  involves 
the  characterization  (modeling)  of  complex  gravitational 
Helds,  including  the  effects  of  Farih  tiguie  and  multihody 
(Harth.  Moon,  Sun)  interactions  that  perturb  the  vehicle  posi¬ 
tion  and  velocity.  As  attitude  control  requirements  become 
more  stringent,  more  precise  models  and  advanced  sensors 
permitting  real-time  drag  acceleration  measurements  will  be 
required  to  complement  existing  inertial  measurement  devices 
and  celestial  sensors. 

Finally,  the  requirements  for  a  six-month  audit  trail  and 
onboard  trend  analysis  to  permit  fault  prediction  and  protec¬ 
tion  necessitates  storage  and  manipulation  of  a  large  volume  of 
data.  Without  ground  iinks.  the  study  participants  believe 
additional  data  storage  capabilities,  coupled  through  the  data 
net  wot  k  to  the  other  spacecraft  subsystems,  will  be  needed. 
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Implementation  Plan 


I.  Introduction 

This  section,  together  with  the  Research  Agenda  of  the 
next  section ,  describes  the  study  participants1  recommended 
plan  of  attack  to  solve  the  problem  that  prompted  the  ASM 
study:  to  satisfy  the  requirement  for  spacecraft  readiness  in 
the  face  of  the  loss  of  ground  stations,  (n  contrast  with  the 
Research  Agenda  that  addresses  medium-  and  long-range 
academic  research  for  an  advanced  ASM  system  of  the  1990s, 
this  section  focuses  on  the  near-term  (next  five  years)  indus¬ 
trial  technology  development  and,  most  importantly,  the 
earliest  possible  system-level,  proof-of-concept  demonstration. 
The  plan  stresses  delivery  of  “product"  in  a  steady  stream 
from  subsystems  to  a  complete  system  for  the  System  Program 
Offices'  consideration  and  introduction  into  flight  programs. 
In  this  sense,  the  plan  is  a  technology  program  that  is  managed 
like  a  project,  with  focused  goals  and  milestones  to  be  met. 
While  there  is  no  provision  for  a  flight  demonstration  in  this 
plan,  a  definite  goal  lias  been  to  provide  a  program  that  will 
generate  continuous  ASM  technology  "fall-out,"  which  can  be 
utilized  in  ongoing  programs  and  in  design  block  changes. 

The  program  described  below  is  preliminary;  the  limited 
resources  of  the  study  precluded  a  detailed  program  develop¬ 
ment  and  cost  estimate.  However,  the  study  participants  feel 
the  proposed  plan  described  contains  the  essentials  of  a 
workable  program  needed  to  meet  the  future  requirements 
of  the  Air  force. 


A.  Purpose 

The  purpose  of  the  plan  is  to  recommend  a  coordinated  set 
of  developments  that  will  give  industry  a  demonstrated  capa¬ 
bility  to  build  an  ASM  spacecraft,  and  hence,  enable  the  Air 
Force  to  change  from  ground-dependent  to  autonomous 
operational  spacecraft  bv  1989. 

B.  Goals 

The  goals  of  the  plan  are: 

( 1  )  To  develop  an  ASM  technology  and  apply  it  as  early  as 
possible  to  existing  programs,  cspecialh  DMSP.  DSP. 
GPS,  and  DSCS  III. 

(2)  To  develop,  by  1985,  a  demonstrated  industrial  capa¬ 
bility  to  produce  autonomous  spacecraft,  so  that  the 
first  operational  launch  may  take  place  by  1989. 

C.  Approach 

The  approach  taken  in  preparing  the  plan  can  be  summa¬ 
rized  in  the  following  points: 

(1)  Involve  as  many  relevant  governmental  and  industrial 
organizations  as  possible.  This  will  create  a  broad  base 
of  ASM  experience,  design,  and  methods. 

(2)  In  support  of  the  first  goal,  begin  work  with  existing 
subsystem  designs:  ASM  implications  and  problems 
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must  be  characterized,  designs  and  breadboards  must 
be  modified,  and  results  demonstrated  early. 

(3)  In  support  of  the  second  goal,  begin  work  on  a  parallel 
system-level  analysis,  design,  and  hardware  program 
leading  to  a  proof-of-concept  demonstration. 

(4)  Use  as  much  available  hardware  as  possible.  Develop 
and  build  as  little  new  equipment  as  possible  to  meet 
requirements.  Acquire  engineering  test  models  of 
actual  and/or  representative  systems/subsystems  of  Air 
Force  satellites. 

(5)  Focus  on  ASM-required  changes  only;  design  life  and 
performance  advancements  not  needed  tor  ASM  should 
not  be  pursued. 

(6)  Hold  frequent  reviews  and  conferences  for  technical 
information  exchange  with  all  concerned  industrial, 
academic,  and  government  organizations. 

II.  General  Plan  Description 

The  study  participants  recommend  that  the  program  con¬ 
sist  of  four  major  elements,  prefaced  by  a  three-month  start-up 
period:  first,  an  activity  addressing  existing  programs  at  the 
subsystem  level,  producing  demonstration  products  within  two 
years;  second,  a  system -level  project  addressing  ASM-enhanced 
Air  Force  programs  with  proof-of-concept  in  five  years;  third, 
applications  research  directed  at  filling  technological  gaps;  and 
fourth,  an  advanced  system  development,  aimed  at  the  IWOs, 
to  provide  an  opportunity  for  unconstrained  research  to 
expand  capabilities  beyond  the  foreseeable  luturc.  These 
elements  are  denoted  as  Tasks  1,2,3,  and  4,  respectively.  The 
advanced  systems  development.  Task  4.  is  identified  for  com¬ 
pleteness,  but  because  its  products  would  not  meet  the  1W> 
launch  requirement,  resources  are  not  identified.  The  Research 
Agenda  elaborates  Task  4. 

A  general  view  of  the  plan  is  shown  in  Fig.  1 ,  in  winch  the 
arrows  indicate  typical  points  of  technology  transfer  between 
tasks  to  tire  System  Program  Offices.  All  tasks  start  at  the 
beginning  of  CYSl  to  allow  program  definition  and  start-up  to 
take  place  in  the  first  three  months  of  FY8I.  Task  1  is  a 
two-year  activity  that  assesses  increased  fault  detection, 
isolation,  and  recovery  for  existing  subsystems.  Design  changes 
will  he  mad*1  and  breadboard  units  will  be  modified  to  test 
ASM  capabilities  and  benefits.  Task  2  is  a  5-ycar  activity  that 
includes  a  top-down  system  development  and  the  necessary 
new  subsystem  technology  developments  required  for  ASM.  A 
pre  Phase  A  effort  is  required  to  prepare  a  procurement  speci¬ 
fication  and  to  select  the  contractor  lor  both  Task  2  and 
Task  3.  In  Phase  A,  the  mission  requirements  and  spacecraft 
design  will  be  established,  while  in  Phase  B,  the  fabrication. 


integration,  test,  and  demonstration  of  the  ASM  system  wall 
be  performed.  Task  3  is  a  five-year  applications  effort  required 
to  develop  new  well-defined  subsystem  technologies.  Task  4, 
through  CY85,  is  performing  the  basic  research  for  a  “second- 
generation"  ASM  system  as  mentioned  earlier. 

III.  Task  Descriptions 

The  layout  of  the  entire  program  is  shown  in  more  detail  in 
Fig.  5.  In  the  view  of  the  study  participants,  the  plan  repre¬ 
sents  the  best  method  of  addressing  the  urgency  of  obtaining 
an  ASM  readiness,  given  the  available  resources.  The  relative 
times  needed  to  accomplish  the  objectives  are  shown;  reduced 
funding  or  delays  in  program  start-up  will  result  in  commen¬ 
surate  delays  in  completing  the  tasks  described  below. 

A.  Task  1 :  Existing  Subsystem  Redesign  to  ASM 

The  first  task  is  a  24-month  effort  to  characterize  the  sub¬ 
systems  involved  with  ASM.  redesign  the  breadboards,  check¬ 
out  subsystem  ASM  functions,  and  provide  measures  ot 
capability  required  to  accommodate  ASM.  These  measures  will 
be  in  such  terms  as  memory  size  and  throughput.  Because  the 
subsystems  are  well  known,  it  is  felt  that  modifying  them  to 
include  ASM  features  will  be  the  quickest  and  most  cost- 
effective  way  to  size  the  challenge  early  and  to  incorporate 
some  ASM  capability  into  the  spacecraft  When  successful!) 
demonstrated,  the  System  Program  Offices  could  consider 
them  for  operational  use. 

It  is  expected  that  much  of  the  design  work,  and  perhaps 
the  breadboards,  would  be  important  to  the  Task  2  effort, 
and  heavy  interaction  between  tasks  should  be  anticipated. 
The  subsystems  to  be  studied  are  (ranked  by  their  ASM 
importance):  attitude  and  articulation  control,  power,  telem¬ 
etry'  and  data  handling  (including  tape  recorders),  payload, 
communications,  propulsion,  and  thermal  control.  St  incline 
and  mechanical  devices  are  not  included  because  their  design 
is  little  impacted  by  ASM  requirements.  It  is  recommended 
that  two  contractors  perform  on  each  subs) stem  *o  gain  a 
diversity  of  experience  for  contractor  and  program  applica¬ 
tion,  As  no  two  designs  are  the  same,  additional  infoimation 
will  he  gained  from  this  approach  to  broaden  the  data  base. 

The  first  six  months  is  spent  on  design  study.  The  subsys¬ 
tem's  fault  characteristics  will  be  examined,  and  the  fault 
detection,  isolation,  and  recovery  techniques  will  be  devel¬ 
oped.  The  hierarchical  assignment  of  fault  recovery  between 
faults  totally  handled  within  the  subsystem  and  those  “passed 
on"  to  the  system  for  action,  will  be  developed.  Evaluation  of 
the  reliability  of  sensors  and  switching,  which  are  essential  to 
“error  free"  ASM.  will  be  done.  Changes  in  design  techniques, 
instrumentation,  and  associated  software  or  firmware  as  well 
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Fig.  5.  Autonomous  spacecraft  maintenance  program 


B.  Task  2:  ASM  System  Demonstration 


as  the  hardware  will  be  covered.  An  assessment  will  be  made  as 
to  what  benefits  accrue  in  reduced  ground  maintenance  with 
the  recommended  ASM  capabilities  in  the  subsystems.  In  the 
next  nine-month  period,  detailed  design  takes  place.  Algo¬ 
rithms  tor  ASM  will  be  defined,  coded,  and  debugged.  Hard¬ 
ware  modifications  and  software  changes  will  be  made.  ASM 
design  tea  lures  may  be  implemented  in  single-string  fashion  so 
that  in  (his  exercise  only  the  subsystem  under  lest  will  be  fault 
l  ole  ran  I . 

In  the  last  year  of  the  program,  the  bieadboards  ot  engi¬ 
neering  test  models  and  associated  support  equipment  will  be 
modified  to  include  the  ASM  featuies.  and  then  tested.  The 
test  inn  will  be  a  ngoiou*  exercising  of  the  lault-piocessing 
logic  be  injection  of  all  types  of  faults.  The  testing  will  provide 
specific  valid  measures  of  ASM  performance  and  design 
requirements  in  such  terms  as  memory  requirements,  speed, 
and  recover)  aigoiiihms  which  can  be  utilized  by  various  pro¬ 
gram  offices  as  appropriate  in  their  ongoing  or  new  programs. 

At  the  conclusion  of  Task  l .  impacts  of  ASM  will  bo  clearly 
established.  Fault  character  will  be  understood,  new  sensor 
and  switching  technology  will  emerge;  software  and  hardware 
will  be  sized  to  do  the  fob;  algorithms  for  handling  faults  will 
be  checked  out .  many  system  issues  will  be  discovered  for 
resolution  in  Task  2.  and  finally,  the  System  Program  Offices 
will  have  an  opportunity  to  assess  ASM  applicability  at  the 
subsystem  level. 


This  second  recommended  task  is  a  five-yeai  activity  that 
ends  in  a  system-level  demonstration  of  ASM  It  ts  laid  out 
very  much  as  a  typical  flight  piojeci  might  be.  but  it  mica  ted  at 
1  ho  system  tesi  of  a  prototype  spacecraft  with  no  ilighi  hard¬ 
ware  built.  The  assumption  is  made  (hat  the  system  demon¬ 
stration  will  be  achieved  b>  applying  ASM  i*>  one  mission, 
such  as  DSP.  D.MSP.  oi  GPS.  but  the  extension  of  this  ASM 
technology  to  all  Air  I  oice  missions  will  be  an  active  design 
consideration.  The  reviews  aie  typical,  with  only  the  System 
Test  Requirements  and  the  Pioof-of-(\mcept  Acceptance 
Reviews  being  unique  to  this  ptogiam.  The  pluses  aie  typical 
a>>  well:  systems  analysis  and  requirement-  generation,  system 
design;  subsystem  design,  lubrication,  and  test.  and  'Astern 
integration  and  test. 

The  anal) ms  and  requirements  activity  proceeds  during  the 
second  year  and  culminates  at  the  Preliminary  Design  Review 
with  the  pioduction  ot  the  Mismou  and  Sy  stem  Requirements 
document.  The  activity  includes  missnm  impacts,  recovery 
strategy,  degradatton  profiles,  and  data  return  sfiategy  as 
faults  occur ;  'ehahiltty  and  risk  analyses;  operation  anaKsis 
with  ASM.  flight  ground  tiadeotfs.  spacectalt  system  fault 
analysts,  development  of  the  “layered"  fatilt  protection  sy  stem 
architecture,  fault  detection,  isolation,  and  recoveiy  at  the  sys¬ 
tem  level,  payload  interaction  with  ASM;  and  in-flight  naviga¬ 
tion  requirements  genet  at  ion. 
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The  ASM  system  design  occurs  during  the  second  and  third 
year,  culminating  at  the  Critical  Design  Review.  The  design 
team  will  study  alternate  design  approaches;  allocate  functions 
between  hardware,  firmware,  and  software;  study  distributed 
vs  central  computing;  analyze  performance;  write  specifica¬ 
tions;  and  have  the  usual  heavy  system/subsystem  interaction 
on  design  (including  Task  l  personnel).  The  key  product  will 
he  the  Spacecraft  System  Specification,  available  at  the  Criti¬ 
cal  Design  Review.  Another  important  part  of  this  period  is 
the  system  test  requirements  to  be  imposed.  The  design  must 
allow  access  for  fault  injections  during  test,  which  may  not  be 
easy  to  implement.  The  System  Test  Requirements  Review 
will  address  adequacy  of  testing  to  prove  that  ASM  has  a 
tlight-ready  capability. 

The  fourth  and  fifth  years  of  the  ASM  system  activity  will 
be  used  to  redesign,  fabricate,  and  test  the  subsystems,  and 
then  integrate  them  and  test  the  system  for  proof  of  concept. 
Wh  ere  possible,  the  subsystems  from  Task  1  will  be  used,  but 
modifications  will  still  have  to  be  made  to  integrate  them  into 
the  overall  system  design.  Redesign,  fabrication,  and  test 
should  take  15  months.  The  subsystems  will  be  delivered  to 
system  test  at  51  months  into  the  project. 

The  test  facility  preparation  starts  at  the  beginning  of  the 
fourth  year,  and  must  he  completed  by  subsystem  delivery. 
Support  equipment  must  be  designed  or  modified  as  needed 
It  must  be  determined  how  the  fault  injection  and  testing  will 
be  done  for  proof-of-concept  testing.  In  addition  to  the  differ¬ 
ent  slates  that  the  facility  will  have  to  test,  it  must  also  be  able 
to  simulate  the  power  source,  thrusters,  spacecraft  dynamics, 
and  mechanical  devices. 

Finally,  system  integration  begins  at  48  months,  and  proof- 
of-concept  testing  begins  at  54  months.  The  system-level  proof 
of  concept  will  be  a  full  electrical  demonstration  of  the  ASM 
system,  under  the  test  conditions  already  mentioned.  Testing 
will  be  performed  in  a  laboratory  ambient  environment. 

Throughout  the  program,  attention  will  be  paid  to  any 
spacecraft  block  changes  to  ongoing  programs  that  may  pro¬ 
vide  an  early  opportunity  for  ASM  application.  Block  changes 
will  not  necessarily  affect  the  ASM  system  demonstration 
project,  but  if  one  occurs  at  an  opportune  time,  some  of  the 
system  development  may  be  directed  toward  it. 

The  Proof-of-Concept  Acceptance  Review'  is  the  final  mile¬ 
stone  in  the  system  activity.  Test  results  would  be  examined 
for  validity  and  completeness,  and  if  the  review  is  success¬ 


ful,  ASM  will  be  demonstrated  as  a  viable,  implementable 
technology. 

C.  Task  3:  Applications  Research 

Task  3  is  a  new  technology  research  and  development 
activity  of  five  years  duration  that  addresses  known  gaps  at 
the  subsystem  level.  Two  are  currently  identified:  a  dis¬ 
tributed  fault-tolerant  data  processor  with  a  nonvolatile  com¬ 
puter  backup  memory,  and  an  autonomous  navigation  sub¬ 
system.  Figure  5  shows  the  development  schedule  tor  these 
items.  It  is  expected  that  the  breadboards  for  these  subsystems 
w'ould  be  used  in  the  system  proof  of  concept.  It  not  avail¬ 
able,  appropriate  simulators/emulators  would  have  to  be 
provided.  Resources  foi  in-flight  navigation  are  not  included 
here  because  it  is  assumed  that  currently-funded  programs 
elsew'here  can  be  expected  to  produce  the  needed  breadboard 
in  1983. 

D.  Task  4:  Advanced  ASM  System  Development 

As  mentioned  earlier,  this  effort  is  comprised  of  the  Re¬ 
search  Agenda  of  the  next  section.  The  products  of  that 
research  will  fold  into  the  ‘‘second-generation"  ASM  system  of 
the  1990s. 

E.  Program  Cost  Estimate 

A  budgetary  cost  estimate  for  Tasks  1 . 2.  and  3  is  shown  in 
Table  7.  This  does  not  include  funds  for  the  development  of 
the  autonomous  navigation  capability,  which  is  assumed  to  be 
handled  in  another  program.  These  figures  should  be  con¬ 
sidered  only  an  estimate  for  several  reasons.  First,  the  cost  of 
developing  the  new  technology  is  not  well  known.  Second,  a 
specific  mission  application  has  not  been  assumed,  and  so 
candidate  spacecraft  could  not  be  assumed.  Finally,  substanti¬ 
ating  data  was  not  provided  by  the  individual  participants. 
For  these  reasons,  a  more  definitive  cost  study  should  be  per¬ 
formed  in  the  initial  phases  of  the  activity. 

IV.  Summary 

The  Implementation  Plan  presented  here,  in  the  view  of  the 
study  participants,  represents  a  balanced,  focused  attack  on 
the  Air  Force's  spacecraft  maintenance  problems.  System,  sub¬ 
system,  and  new’  technology  elements  are  all  pursued  at  a  level 
sized  to  the  difficulty  of  the  specific  ASM  challenge  while 
recognizing  the  needs  for  early  demonstrable  results  for  on¬ 
going  operational  programs.  The  above  described  implementa¬ 
tion  plan  is  recommended  by  study  participants  as  the  basis 
for  the  Air  Force's  ASM  program. 
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Table  7.  ASM  program  resource  estimate 


Program 

resources.  $kJ 

ask 

Program  element 

CY81 

(  Y82 

(Y83 

(  Y84 

(  Y85 

Totals 

1 

l*\tstine  subsystems1' 
redesign  to  ASM 

2.900 

3.500 

800 

7,200 

2 

ASM  system  designv 
and  demonstration 

500 

4.500 

7.500 

7.500 

3.000 

23.000 

3 

Applications  research 

600 

800 

1.300 

2.300 

1.200 

6.20U 

I  otals 

4.000 

8,800 

9.600 

9.800 

4.2oo 

36.400 

*(  ontuctor  costs  onl>  \l  procurement  and  management  costs  not  included,  autonomous  navigation  development  not  meluded 
I  leures  are  l  Y8()  dollars 
h  I  \%o  contractors  per  subssstem  assumed 
Single  svstem  contractor  assumed 


Research  Agenda 


I.  Introduction 

A  research  program  to  support  the  development  of  auto¬ 
mated  spacecraft  maintenance  must  focus  on  the  most  critical 
problems  expected  in  that  development.  A  major  challenge  is 
to  channel  a  great  deal  of  fault-tolerance  expertise,  developed 
for  other  applications,  into  work  that  will  specifically  benefit 
the  space  program.  Fortunately,  most  of  the  ASM  spacecraft 
problems  are  shared  by  many  other  applications  (e.g..  process 
control,  avionics,  and  robotics)  and  are  sufficiently  general  in 
scope  to  be  of  considerable  interest  to  the  academic  com¬ 
munity.  This  proposed  Research  Agenda  is  organized  around 
specific  spacecraft  development  problems.  An  underlying 
cause  of  most  of  these  problems  is  increasing  complexity. 
The  basic  motive  force  is  rapidly  expanding  capabilities  of  I  SI 
and  V LSI  technology.  Until  very  recently ,  satellites  contained 
a  tew  hundred  to  a  lew  thousand  integrated  circuits.  I  acli 
integrated  circuit  contained  a  lew  gales  or  registers,  and  the 
collection  of  integrated  circuits  were  combined  to  form  a 
system.  We  will  soon  tly  single  VLSI  chips  that  contain  thou¬ 
sands  of  gates  and  memory  cells  such  that  each  chip  is  itselt  a 
complex  subsystem  in  a  liny  package.  This  can  result  in  an 
enormous  increase  in  functional  capabilities  in  satellites 
Onboard  navigation,  very -high-performance  signal  processing, 
threat  evasion,  pattern  recognition,  and  a  host  of  other  capa¬ 
bilities  will  become  feasible. 


It  is  expected  that  fault  tolerance  will  be  an  important 
attribute  of  VLSI  design  because  of  the  problems  of  transient 
faults  and  testability.  The  very  high  complexity  of  large  VLSI 
systems  is  expected  to  result  in  transient  faults  every  few 
minutes,  or  every  few  hours.  Current  experience  indicates  a 
transient  error  rale  in  LSI  memory  of  one  error  per  hour  per 
million  bits,  f  ven  if  this  rale  is  reduced  an  order  of  magnitude, 
impaired  operation  will  occur  unless  the  spacecraft  system  is 
designed  to  detect  and  recover  automatically  from  these  fault 
conditions  The  problem  of  thoroughly  testing  complex  VLSI 
circuits  has  only  recently  been  recognized.  Many  existing 
devices  are  essentially  untestable  and  design  taults  are  uncov¬ 
ered  in  the  field  after  prolonged  usage.  Since  the  only  access  to 
a  finished  device  is  th tough  a  limited  number  of  pins,  it 
becomes  nearly  impossible  to  exercise  all  internal  states  of  a 
device  containing  thousands  of  transistors.  Testable  design 
methodologies  have  been  recognized  as  a  high-priority  research 
problem  in  industry,  and  is  even  more  critical  for  space  appli¬ 
cations. 

New  and  laigely  unexplored  problems  are  expected  at  the 
system  architecture  level  of  space  systems.  Proliferation  of 
specialized  microelectronic  controllers  in  spacecraft  sub¬ 
systems  will  lead  to  more  complex  cooperation  between  sub¬ 
systems,  between  t he  spacecraft  and  ground,  and  pcihaps 
between  different  spacecraft.  Consequently,  the  system 
organization,  software,  and  fault-tolerant  aspects  of  space- 


craft  will  have  to  become  correspondingly  more  complex.  A 
hierarchy  of  computing  processes  is  envisioned.  This  implies 
more  onboard  monitoring  circuitry  to  detect  faults  before 
errors  propagate  through  the  system,  making  diagnosis  and 
recovery  extremely  difficult.  Automatic  trend  analysis  may  be 
employed  to  record  and  discover  new  error  patterns,  and 
heuristic  recovery  algorithms  may  be  required  to  recover  from 
unanticipated  faults. 

In  summary,  there  exist  a  variety  of  research  areas  that  are 
rich  in  both  substance  and  applicability,  and  are  essential  to 
the  development  of  future  space  systems. 

II.  Research  Plan 

Re  cognizing  that  resources  are  limited,  the  following  re¬ 
search  plan  is  broken  into  five  areas  that  are  essential  to  future 
ASM  development:  (1)  VLSI  technology,  (2)  architecture  of 
advanced  ASM  systems.  (3)  software  fault  tolerance.  (4)  mod¬ 
eling  and  analysis,  and  (5)  supporting  development.  In  terms 
of  criticality,  they  are  listed  in  descending  order.  Subsystem 
technology  and  especially  related  VLSI  issues  must  he  resolved 
no  matter  what  architecture  is  chosen.  An  understanding  of 
system  architecture  is  necessary  to  make  modeling  and  analysis 
move  useful  and  relevant. 

A.  VLSI  Technology 

Testing  of  LSI  devices  is  a  serious  and  expensive  problem 
in  current  spacecraft.  It  will  be  a  critical  issue  in  ASM  systems 
because  it  is  necessary  to  detect  faults  very  quickly  alter  (hen 
occurrence,  so  that  autonomous  recovery  mechanisms  can 
restore  the  spacecraft  to  normal  operation  with  minimal  dis¬ 
ruption  of  performance.  This  research  area  has  two  compo¬ 
nents:  ( 1  )  self  testing  VLSI,  and  (2)  on-chip  redundancy  . 

1  Self-testing  VLSI  The  first  goal  of  this  component  is 
tii  develop  methodologies  to  design  VLSI  chips  that  are 
I  I  )  thoroughly  testable  prior  to  normal  operation,  and  (2)  self- 
checking.  A  methodology  for  designing  selfchecking  circuitry 
lias  been  developed  that  allows  the  chip  to  detect  internal 
faults  concurrent  with  normal  operation.  We  must  learn  to 
design  a  chip  that  will  be  fully  exercised  and  tested  during 
normal  operation.  Lven  it  we  can  detect  a  fault  when  it  occurs, 
it  may  he  months  or  years  before  a  complex  chip  in  normal 
operation  enters  a  faulty  state.  Thus,  development  of  “easily" 
testable  circuits  is  a  high-priority  research  item. 

2.  On-chip  redundancy.  A  second  goal  ol  this  research  is  to 
investigate  the  use  of  on-chtp  redundanev  to  improve  yield  amJ 
chip  reliability.  Although  the  existence  of  catastrophic  failure 
modes  make  it  necessary  to  back  up  individual  chips  with 


spares,  the  use  of  on-chip  redundancy  may  greatly  improve 
chip  reliability  and  system  life. 

B.  Architecture  of  Advanced  ASM  Systems 

This  area  includes  the  hardware  and  software  organization 
to  achieve  fault  tolerance  in  highly  complex  ASM  spacecraft. 
This  work  must  take  into  account  the  trend  toward  prolifera¬ 
tion  of  computers  in  spacecraft  subsystems,  and  it  should  be 
directed  toward  future  space  systems  in  which  dozens  of  dis¬ 
tributed  computers  may  be  used.  It  should  address  the  impacts 
of  VLSI  in  spacecraft  architecture,  performance,  and  ASM 
capability  It  is  expected  to  support  ASM  spacecraft  develop¬ 
ment  beyond  1990. 

To  effectively  involve  the  academic  community  in  space¬ 
craft  system  research,  it  will  probably  be  necessary  for  the 
LSAF  to  develop  a  set  of  strawman  system  requirements. 
Most  members  of  the  academic  community  are  not  familiar 
with  the  unique  problems  of  space  systems  (e.g.,  power, 
weight,  volume,  uplink  and  downlink,  instruments,  testability, 
command  interfaces,  and  subsystem  operation).  Thus  careful 
problem  definition  is  required  to  focus  this  work  toward  real 
space  problems.  Such  strawman  systems  might  include  a  robot 
for  in-space  assembly,  or  a  satellite  that  must  correlate  and 
make  decisions  on  multiple  sensor  inputs. 

The  following  architectural  tasks  aie  highly  mien  elated 
(e.g..  hardware  and  operating  systems  studies  t.  and  mcchanjMMs 
for  fiequent  interchange  of  information  between  gioups  wank¬ 
ing  in  this  area  are  veiy  important.  A  series  of  workshops  might 
be  one  such  mechanism. 

The  following  tasks  have  been  identified:  (1  )  organization 
studies.  (2)  opeutmg  systems  I’oi  large  hierarchic  space  ws- 
tents.  (3)  iccoveiy  by  problem  solving.  (4)  fault  tolerance 
in  wiv -high-perfoi  inance  piocessoiv.  (5)  aichiuvtutc 
development . 

I'ndcrhing  Tasks  I.  2.  and  3  is  the  need  to  deu*lop  a  hiei 
aiehic  model  of  complex  distubuted  functions  m  ASM  space 
ci  aft.  and  models  of  the  m  lei  faces  between  spaceciaft  subsys¬ 
tems.  Computing  in  each  spacecraft  subsystem  geneiates  ,i 
“viitual"  digital  intei face  between  the  subsystem  and  the 
spacecraft  system.  Models  of  these  intei  faces  should  in  Jude 
genet ah/ed  fault  monitoring  and  recovery  functions  at  each 
level  of  the  hierarchy.  Such  models  may  lead  to  insights  on 
how  to  stiuciure  these  mieitaces  to  improve  soltwaie  reliabil¬ 
ity.  and  fault  recovery,  as  well  as  simplified  commanding  and 
system  integration. 

1.  Organization  studies.  These  studies  will  include  postu¬ 
lating  fault-tolerant  distubuted.  and  hierarchical  computci 
architectures  along  with  communication  formats,  arid  software 
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executive  structures  that  are  applicable.  The  first  goal  of  this 
component  is  to  perform  tradeoffs  and  pinpoint  the  relative 
capabilities  and  limitations  of  the  postulated  architectures 
with  respect  to  spacecraft  performance  and  fault  tolerance. 
The  second  goal  is  to  develop  specific  fault-tolerance  tech¬ 
niques  for  use  in  these  types  of  systems.  Among  the  fault- 
tolerance  questions  to  be  addressed  are. 

( 1 )  How  can  reliable  clocking  and  synchronization  be 
carried  out  between  the  multiple  processors? 

(2)  How  can  embedded  processors  with  their  numerous 
input/output  pms  be  spared? 

(3)  How  can  nonhomogeneous  specialized  processors  be 
handled,  especially  when  fault-tolerant  architectures 
are  biased  towards  a  homogeneous  pool  of  processors? 

(4)  How  is  executive  software  organized  to  support  re¬ 
covery.  rollback,  and  diagnosis? 

(5)  Can  the  system  be  designed  to  tolerate  software  errors 
through  fault -containment? 

(6)  How  does  one  design  virtual  interfaces  that  partition 
software  between  various  computer  modules? 

(7)  How  is  redundancy  distributed?  What  fault  detection 
is  provided  at  the  various  sensor/actuator  levels  within 
the  computer,  subsystem,  and  system  levels?  What 
are  the  levels  of  sparing  employed  on  chips,  between 
chips,  and  between  subsystems? 

(X)  How  well  can  fault -tolerance  features  be  made  trans¬ 
parent  to  the  user1’ 

2.  Operating  systems  for  large  hierarchic  space  systems. 
Tins  research  is  directed  at  developing  operating  system  con¬ 
cepts  best  suited  to  complex  distributed  systems.  Issues  to  be 
addressed  are: 

(1)  Hierarchical  partitioning  of  executive  functions 
global /local. 

(21  hffect  of  alternative  executive  structures  on  applica¬ 
tion  software  reliability,  testability,  and  fault- 
containment. 

(3)  Interaction  of  executive  with  hardware  and  software 
fault -tolerance  mechanisms. 

1 4 )  Provability  of  correctness  of  the  executive. 

(>)  Robustness  the  ability  of  the  operating  system  to 
survive  errors  in  applications  software. 

3.  Recovery  by  problem  solving.  Many  of  the  techniques  of 
artificial  intelligence  and  problem  solving  may  be  applicable  in 
dealing  with  unanticipated  fault  conditions,  or  with  operator 
errors.  Tins  task  is  intended  to  develop  heuristic  techniques  to 


deal  with  this  class  of  unexpected  faults  and  possibly 
some  errors. 

4.  Fault-tolerant  high-performance  processors.  Tins  area 
includes  the  processors  that  will  be  or  are  being  developed 
(e.g.,  signal  processors).  Techniques  to  achieve  fault  detection 
and  recovery,  and  also  to  integrate  such  systems  in  ASM  satel¬ 
lites,  require  investigation.  This  is  especially  true  because  many 
of  these  systems  will  probably  not  work  without  embedded 
fault  tolerance  due  to  a  high  transient  error  rate  brought  on  by 
enormous  complexity. 

5.  Architecture  development.  To  use  ASM  in  a  satellite, 
the  supporting  technology  must  be  in  place.  Project  offices 
are  usually  in  no  position  to  accept  the  delay  and  risk  of 
developing  new  technology.  Thus,  this  research  program 
should  develop  one  or  more  fault-tolerant  computer  system 
architectures  to  at  least  the  breadboard  stage.  Fault-tolerant 
architectures  are  sufficiently  complex  that  it  is  necessary  to 
build  and  test  them  to  understand  their  behavior.  It  is  expected 
that  the  selection  and  design  of  these  architectures  would  be 
outgrowths  of  cunem  architecture  developments  (Software 
Implemented  Fault  Tolerance.  Fault-Tolerant  Multiprocessor. 
Fault-Tolerant  Spaceborne  Computer,  and  Building  Block 
Fault-Tolerant  Computer),  which  would  be  heavily  influenced 
by  the  organization  studies  above. 

C.  Software  Fault  Tolerance 

This  research  area  is  concerned  with  developing  reliable 
software  for  distributed  computer  systems  for  ASM  space¬ 
craft.  It  includes  three  areas  of  study:  (1 )  system  partitioning 
and  interface  definition  to  improve  software  reliability, 
(2)  self-checking  flight  software,  and  (3)  fault-tolerant 
software. 

1.  Partitioning  and  interface  definition.  This  task  is  tightly 
coupled  with  the  architecture  studies.  The  partitioning  of 
functions  within  a  distributed  system  and  the  virtual  inter¬ 
faces  between  subsystems  have  a  very  large  impact  on  the 
complexity  and  reliability  of  applications  software.  Tire  goal 
of  this  research  is  to  study  tradeoffs  between  alternate  parti¬ 
tioning  and  interface  (command  and  data)  definitions  and  their 
impacts  on  software  complexity  and  reliability.  (Such  issues  as 
the  degree  of  system  vs  local  control  of  a  subsystem,  timing 
requirements  on  commands,  acceptable  communications 
delays,  scheduling  strategy,  and  internal  software  structure, 
are  involved  in  these  studies.) 

2.  Self-checking  flight  software.  One  goal  of  this  task  is  to 
develop  methodologies  for  detecting  faults  in  applications 
software  as  it  is  performing  its  normal  operations  This  in¬ 
cludes  the  inclusion  of  acceptance  tests  in  the  flight  programs 
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and  a  variety  of  other  software  fault  detection  mechanisms.  A 
second  goal  of  this  task  is  to  develop  verification  and  valida¬ 
tion  techniques,  to  prove  the  effectiveness  of  this  self-checking 
code. 

3.  Fault-Tolerant  software.  This  task  is  intended  to 
develop  techniques  for  developing  software  that  operates  in 
the  presence  of  programming  errors.  This  is  a  difficult  area  that 
involves  the  use  of  software  fault  detection  and  the  execution 
of  redundant  code  to  recover  front  design  faults. 

D.  Modeling  and  Analysis 

In  the  development  of  advanced  ASM  spacecraft  systems,  it 
is  necessary  to  develop  experimental  testing  techniques  to 
verify  the  effectiveness  of  the  built-in  fault-tolerance  mecha¬ 
nisms.  Analytic  statistical  models  that  use  these  experimental 
results  and  component  failure  rates  are  then  required  to  pre¬ 
dict  the  leliability  and  performability  of  the  ASM  spacecraft 
as  a  function  of  time.  This  type  of  modeling  is  essential  to 
determine  if  a  given  spacecraft  design  will  meet  its  objectives, 
or  to  perform  tradeoffs  between  competing  design  approaches. 

A  second  class  of  tools  needed  in  ASM  development  are 
functional  models  and  design  languages  that  can  facilitate 
design  and  verification  of  ASM  systems.  Such  tools  could 
provide  the  capability  of  specifying  and  simulating  operations 
of  proposed  systems,  and  allow  changes  and  improvements 
before  a  design  is  locked  into  hardware.  A  second  important 
use  of  design  languages  and  functional  models  is  to  provide  a 
basis  for  formal  verification  of  a  design  helot e  launch,  and 
validation  of  command  sequences  to  an  orbiting  ASM 
spacecraft. 

The  modeling  and  analysis  area  is  broken  into  three  compo¬ 
nents  (!)  experimental  testing.  (2)  statistical  modeling,  and 
(3)  functional  description,  modeling,  and  verification. 

1.  Experimental  testing.  Spacecraft  testing,  already  a  dif¬ 
ficult  problem,  will  become  considerably  more  complex  with 
the  introduction  of  ASM  A  significant  problem  is  how  to 
test  these  functions  that  arc  dedicated  to  autonomous  mainte¬ 
nance.  The  goal  of  this  component  is  to  acquire  a  deeper 
understanding  of  testing  problems  peculiar  to  ASM,  and 
develop  test  generation  and  test  applications  methods  for 
solving  these  problems.  Among  the  prohlems  to  be  considered 
that  complicate  testing  are:  (I)  testing  at  many  levels  in  a 
hierarchy,  (2)  the  possibility  of  many  combinations  of  input 
events  and  main  unanticipated  faults.  (3)  the  need  to  test  in 
an  artificial  environment.  (4)  wear-out  phenomena,  and 
(5)  the  development  of  specific  tests  lequired  by  statistical 
reliability  models. 


2,  Statistical  modeling.  Probabilistic  models  of  ASM  space¬ 
craft  are  needed  to  assess  the  probabilities  of  performing  at 
various  levels,  ranging  from  full  performance  to  failure,  over 
the  projected  life  of  the  spacecraft.  Such  models  are  being 
developed,  but  have  yet  to  be  extended  to  complex,  hetero¬ 
genous  spacecraft  systems.  The  goal  of  this  component  is  to 
extend  current  methods,  developed  primarily  for  computer 
applications,  to  accommodate  additional  complexities  in 
large,  heterogeneous  spacecraft  systems.  A  considerable 
advancement  is  required  over  existing  models  to  deal  with  the 
complexity  resulting  from  dependent  subsystem  failures,  and 
the  models  must  carefully  relate  to  testing  results  as  input 
parameters.  Special  emphasis  must  be  placed  on  modeling  and 
analysis  of  transient  faults,  since  transients  are  expected  to  be 
a  major  problem  of  VLSI  technology. 

3.  Functional  description,  modeling,  and  verification. 

Spacecraft  systems  are  complex,  multifunctional  real-time  sys¬ 
tems  with  many  different  types  of  physical  subsystems. 
Although  functional  models  may  exist  for  many  subsystems, 
functional  descriptions  at  the  spacecraft  level  are  typically 
informal  and  incomplete  With  the  additional  complexities  of 
VLSI  and  autonomous  maintenance,  informal  design  methods, 
particularly  at  the  system  level,  may  no  longer  produce  the 
desired  results  (witness  the  evolution  of  computer  operating 
system  design  methods). 

One  goal  of  this  component  is  to  investigate  whether 
design  languages,  such  as  those  being  used  in  the  context  of 
computer  and  computer-based  systems,  can  be  usefully  ex¬ 
tended  to  facilitate  spacecraft  design.  Of  particular  relevance 
are  languages  that  call  for  timeliness,  fault  tolerance,  distri¬ 
buted  resources,  and  concurrent  (parallel)  execution  of  tasks. 

A  second  related  goal  is  to  develop  uniform  functional 
models  (abstract  representations)  of  autonomously  maintained 
spacecraft.  The  models  sought  are  hierarchical  models  that 
relate  high-level  functional  behavior  of  the  total  system  to 
lower-level  subsystem  functions  and  interactions,  both  during 
normal  operation  and  in  various  modes  of  fault  recovery  or  of 
degraded  operation.  This  type  of  model  can  facilitate  the 
design  process  and  may,  in  the  future,  lead  to  design  automa¬ 
tion  tools  for  spacecraft  design.  Functional  models  might  also 
be  used  to  formally  verify  the  system. 

With  the  increase  in  logical  complexity  required  for  advanced 
ASM  spacecraft,  model-based  evaluation  and  testing  may  not 
suffice  to  provide  the  desired  confidence  in  the  system.  The 
third  goal  is  to  investigate  the  possibility  of  extending  formal 
verification  methods  (such  as  those  being  developed  for  pro¬ 
grams.  operating  systems,  and  at  least  one  avionics  processor) 
so  as  to  apply  to  formal  descriptions  of  spacecraft. 
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The  areas  of  specification  language,  formal  functional 
models,  and  formal  verification  techniques  are  intimately 
related,  and  are  thus  grouped  into  one  component  in  this 
plan.  This  represents  long-term,  high-risk  research,  but  the 
payoff  can  he  enormous 

E.  Supporting  Development 

Two  supporting  developments  have  been  suggested  by  the 
research  group.  The  first,  of  immediate  urgency,  is  ASM  data 
base  development  The  second  is  development  of  a  spacecraft 
laboratory  for  ASM  integration  patterned  after  a  similar 
development  within  NASA. 

1 .  Data  Base  Development.  A  comprehensive  data  base 
should  be  established  for  ASM  development.  It  should  serve 
as  a  repository  of  two  types  of  data. 

The  first  is  statistical  data  required  to  determine  values  of 
parameters  for  reliability  and  performance  models.  Currently 
used  data  is  often  incomplete  and  inaccurate.  Data  sought 
should  include  piecepart  failure  data  (particularly  transient 
failures),  data  on  VLSI  failure  mechanisms,  and  data  on  sub¬ 


system  failures,  system  failures,  and  that  on  the  environment 
gathered  from  past  missions. 

The  second  type  of  data  is  information  on  existing  (perhaps 
generic)  spacecraft  systems  and  subsystems,  and  information 
on  redundancy  and  ASM  techniques  already  being  used  on 
spacecraft.  There  is  a  significant  problem  of  technology  trans¬ 
fer  between  spacecraft  designers  and  researchers.  This  type  of 
data  base  would  provide  a  multidiscipline  exchange  that  may 
be  indispensable  in  advancing  the  state  of  the  art  in  ASM. 

2.  Spacecraft  Laboratory.  This  is  a  much  more  ambitious 
development.  It  would  consist  of  a  computing  facility  for  ASM 
spacecraft  integration  (analogous  to  NASA’s  Airlab  for  avion¬ 
ics  systems).  This  is  envisioned  as  a  facility  where  spacecraft 
simulations  would  be  provided.  New  hardware/software  sub¬ 
systems  could  be  integrated  and  tested  using  the  system,  and 
new  system  designs  could  be  developed  and  simulated.  Such  a 
facility  would  be  used  for  experimental  testing  of  prototype 
spacecraft  systems.  It  would  be  national  in  scope  and  provide 
both  access  and  a  focus  for  information  exchange  between 
manufacturers  and  researchers. 
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Conclusions  and  Recommendation 


ASM  is  a  logical,  evolutionary  change  to  the  Air  Force's 
concept  of  space  system  operations  that  results  in  the  transfer 
of  functions  from  the  ground  segment  to  the  space  segment. 
With  ASM.  the  role  of  the  ground  segment  becomes  one  of 
supervisory  control  and  operations  management,  rather  than 
detailed  control  of  operations.  Experience  has  shown  that, 
generally,  spacecraft  have  enough  spares  to  meet  mission  life¬ 
time  requirements,  so  additional  redundant  parts  are  not 
necessarily  needed  for  ASM. 

In  the  opinion  of  the  study  participants,  the  present  system 
and  current  spacecraft  operate  quite  well  in  that  mission  objec¬ 
tives  and  user  data  needs  are  satisfied.  The  present  space  seg¬ 
ment.  however,  was  designed  to  operate  with  man  and  his 
ground  control  function  as  an  integral  element.  Successful 
space  segment  operation  currently  requires  closure  through  the 
ground  segment  both  before  and  after  the  occurrence  of  faults. 
ASM  will  remove  this  requirement  from  the  day-to-day  activ¬ 
ities  of  space  segment  operations. 


I.  Conclusions 

The  following  conclusions  are  those  of  the  study  group 
participants  and  result  from  analysis  of  the  material  developed 
during  this  study. 


1.  ASM  would  reduce  the  vulnerability  problem.  There  is  a 
need  to  decrease  space  segment  dependence  on  the  ground 
segment  because  the  ground  segment  is  vulnerable  to  both 
hostile  action  and  operator  error.  By  eliminating  dependence 
on  the  ground  segment  for  fau’l  detection,  isolation,  and 
recovery  management,  and  for  routine  operations  functions 
such  as  power  management  and  ephemeris  updating,  space 
system  vulnerability  will  be  significantly  reduced. 

2.  The  ASM  capability  need  not  impose  operational  con 
straints  on  the  system  user.  If  anything,  the  user  should  per¬ 
ceive  a  more  responsive  spacecraft  with  ASM  present  New 
procedures  lor  user  system  operations  and  data  retrieval 
should  not  be  required.  Data  outage  resulting  from  most 
internal  faults  would  be  reduced  from  hours  to  seconds, 
making  the  ASM  capability  virtually  transparent  to  the  space 
segment  data  user 

3.  ASM  would  require  a  change  in  the  conduct  of  opera 
tions  and  control.  The  role  of  the  ground  segment  in  system 
operations  must  be  redefined.  Detailed  control  of  routine 
operations  and  maintenance  functions  would  be  assumed  h> 
the  space  segment,  with  supervisory  ground  control  Supervi¬ 
sory  control  would  be  maintained  by  an  audit  trail  capabilus 
that  would  provide  nomeal-time  tup  to  6  months)  visibility 
into  maintenance  actions,  and  by  the  capability  for  ground 
segment  override  of  space  segment  autonomous  actions 
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4.  ASM  would  add  complexity  to  the  spacecraft  design; 
therefore,  new  methods  for  specifying,  testing,  and  validating 
ASM-augmented  spacecraft  are  needed.  Concepts  for  specify¬ 
ing,  testing,  and  validating  ground-based,  fault-tolerant  pro¬ 
cessing  systems  have  recently  been  developed.  Interaction 
between  computer  and  spacecraft  technologists  during  this 
study  has  shown  these  concepts  to  be  applicable  to  ASM  New 
methodologies  for  design  and  analysis  are  required  to  address 
such  issues  as  fault  coverage  and  recovery  latency  .  measures  o! 
et  fee  liveness,  risk  assessments,  and  proof-of-correctness. 

5.  A  more  effective  means  of  transferring  technology  from 
research  to  applications  programs  would  be  required.  The  ASM 

study  has  served  as  a  forum  for  the  exchange  ot  technology 
between  researchers  and  application  specialists.  A  continuation 
of  information  exchanges  between  these  two  communities  will 
increase  the  level  of  aw  areness  of  both  the  technological  prob¬ 
lems  and  their  potential  solutions.  As  noted  above  in  item  4, 
the  collective  experience  of  fail  It -tolerant  data  processing  sys¬ 
tem  specialists  can  serve  as  a  surrogate  for  guiding  the  evolu¬ 
tion  of  new  spacecraft  methods  and  new  technologies  required 
to  satisfy  space  segment  environmental  constraints. 

6  New  technology  developments  would  be  required.  Two 

specific  technological  developments  were  identified: 

(1)  A  highly  reliable  fault-tolerant  computing  capability 
with  nonvolatile  back-up  memory  to  enable  autono¬ 
mous  maintenance. 

(2)  An  autonomous  navigation  capability  to  enable  inde¬ 
pendence  of  routine  ground  operations. 

The  fault-tolerant  computing  system  is  expected  to  have 
complete  authority  over  spacecraft  resources  employed  during 
reconfiguration  by  using  hierarchical  recovery  management 
algorithms,  diagnostic  test  procedures,  fault-trail  reporting 
mechanisms,  and  normal  spacecraft  operations.  This  authority- 
must  manage  contention  for  system  resources  and  manage 
subsystem  interdependencies  arising  during  anomolous  opera- 
turns  The  conceptual  design  requirements  for  60-day/6-month 
autonomy  necessitates  moving  the  navigation  function  from 
the  ground  to  the  spacecraft. 

7  A  strong  corporate  commitment  to  ASM  by  the  Air 
Force  would  be  required  to  make  ASM  successful.  The  imple¬ 
mentation  of  ASM  would  be  a  phased  program,  with  the 
spacecraft  fleet  evolving  from  non -ASM  to  ASM  spacecraft 
over  a  period  of  several  years.  The  spacecraft  would  not 


instantly  become  totally  autonomous.  The  pace  of  ASM 
development  and  implementation  would  depend  upon  the 
resources,  technology,  and  chosen  program  applications  that 
are  provided.  To  plan  the  implementation  of  ASM  and  coordi¬ 
nate  the  actions  of  the  System  Program  Offices  and  the 
ground  segment,  a  strong,  long-term  corporate  commitment 
would  he  needed  Tins  would  insure  successful  integration  of 
ASM  into  the  Air  Force's  space  system 

K  Confidence  in  ASM  must  be  instilled  by  creation  of  a 
systematic  modeling,  analysis,  and  demonstration  program. 

Total  confidence  in  ASM  will  result  only  after  operations  are 
proven  to  be  predictable  and  understandable  llowcvei. 
proot-ot -concept  demonstrations  oi  such  individu.il  ASM 
capabilities  as  battery  reconditioning,  autonomous  recovery 
from  bus  undervoltage  conditions,  and  autonomous  computer 
sell -diagnoses,  will  help  provide  early  confidence  in  ASM. 
Confidence  will  be  further  established  during  the  transition 
phase  when  quantitative  figures  of  merit  tor  ASM  and  non- 
ASM  strategies  can  he  developed  wit  fun  the  flight 
environment. 

9.  ASM  is  a  viable  concept  ASM  is  the  technological 
infusion  of  ground-based  functions  into  long-lived,  highly- 
reliable  spacecraft.  These  functions  are  well  understood  and 
operating  successfully  on  the  ground  now.  Precepts  borrowed 
from  fault -tolerant  computing  will  provide  guidance  for  eval¬ 
uation  ot  tauli-detectioii.  isolation,  and  recovery  techniques 
appropriate  to  the  space  environment.  Othei  studies  are  in 
progress  that  will  provide  insight  into  the  solution  of  the 
autonomous  navigation  problem,  and  no  other  technology 
gaps  have  been  identified.  Thus.  ASM  is  workable  and.  given 
the  urgency  of  the  present  situation,  it  should  be  started  now  . 

II.  Recommendation 

The  study  group  recognizes  the  need  for  ASM.  and  has 
found  the  technology  available  in  today  's  spacecraft  systems 
to  he  a  good  foundation  from  which  to  proceed  to  ASM 
The  plan  presented  is  practicable;  it  aims  at  a  series  of  prudent, 
gradually  expanding  (from  subsystem  to  system  level )  capabil¬ 
ity  demonstrations.  The  study  group  therefore  recommends 
that  the  Air  Force  proceed  with  (lie  technology  development 
and  research  programs  as  outlined  in  the  Implementation 
Plan  and  Research  Agenda.  These  programs  would  provide 
t he  earliest  possihle  demonstration  of  ASM  as  a  valid  system 
level  capability,  and  lay  the  research-oriented  groundwork  for 
the  “second  generation”  ASM  of  the  lc>90s 
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